Loading ...
Sorry, an error occurred while loading the content.

Re: signal 11 with postfix-2.11-20130426-nonprod

Expand Messages
  • Ralf Hildebrandt
    ... Working on that. I can already say that the error was introduced between postfix-2.11-20130418-nonprod and postfix-2.11-20130421-nonprod ... No and no. ...
    Message 1 of 5 , May 5, 2013
    View Source
    • 0 Attachment
      * Viktor Dukhovni <postfix-users@...>:
      > On Sun, May 05, 2013 at 08:38:20PM +0200, Ralf Hildebrandt wrote:
      >
      > > May 5 20:35:31 mail postfix/qmgr[2890]: warning: transport smtp failure -- see a previous warning/fatal/panic logfile record for the problem description
      > > May 5 20:35:31 mail postfix/master[2888]: warning: process /usr/lib/postfix/smtp pid 2954 killed by signal 11
      >
      > Thanks. Do you have a stack trace or core dump? If you have a Skype or
      > Google+ account, perhaps we can fix this off list... Drop me a note with
      > your contact details.

      Working on that. I can already say that the error was introduced between
      postfix-2.11-20130418-nonprod
      and
      postfix-2.11-20130421-nonprod

      > Otherwise, did you enable DNSSEC lookups? Did you enable "dane" security?

      No and no.

      > Was the destination for the deferred message a site that offers STARTTLS?

      Can't really tell.

      > Any earlier log entries from the process 2954?

      No, none at all (I just grepped for it)

      --
      [*] sys4 AG

      http://sys4.de, +49 (89) 30 90 46 64
      Franziskanerstraße 15, 81669 München

      Sitz der Gesellschaft: München, Amtsgericht München: HRB 199263
      Vorstand: Patrick Ben Koetter, Axel von der Ohe, Marc Schiffbauer
      Aufsichtsratsvorsitzender: Florian Kirstein
    • Viktor Dukhovni
      ... Ralf sent be a stack trace captured via: http://www.postfix.org/DEBUG_README.html#screen problem fixed in the next snapshot. Nested macros need to be
      Message 2 of 5 , May 6, 2013
      View Source
      • 0 Attachment
        On Sun, May 05, 2013 at 06:44:23PM +0000, Viktor Dukhovni wrote:

        > > May 5 20:35:31 mail postfix/master[2888]: warning: process /usr/lib/postfix/smtp pid 2954 killed by signal 11
        >
        > Thanks. Do you have a stack trace or core dump?

        Ralf sent be a stack trace captured via:

        http://www.postfix.org/DEBUG_README.html#screen

        problem fixed in the next snapshot. Nested macros need to be careful with temporary
        variable names:

        Bug:

        #define foo(x) do { FOO *_t = x; bar(_t); /* code using _t */; }
        #define bar(x) do { FOO *_t = x; /* code using _t */; }

        Fix:

        #define foo(x) do { FOO *_t1 = x; bar(_t); /* code using _t1 */; }
        #define bar(x) do { FOO *_t2 = x; /* code using _t2 */; }

        Another fix:

        #define TMPVAL(T, val, var) T __tmpin__ = val; T var = __tmpin__
        #define foo(x) do { TMPVAL(FOO *, x, _tmp); bar(_tmp); /* code using _tmp */; }
        #define bar(x) do { TMPVAL(FOO *, x, _tmp); /* code using _tmp */; }

        --
        Viktor.
      • Wietse Venema
        ... Technical nit: this bug is not specific to nested macros. Name collisions with temp variables may happen for other reasons. Just like macro names must be
        Message 3 of 5 , May 6, 2013
        View Source
        • 0 Attachment
          Viktor Dukhovni:
          > On Sun, May 05, 2013 at 06:44:23PM +0000, Viktor Dukhovni wrote:
          >
          > > > May 5 20:35:31 mail postfix/master[2888]: warning: process /usr/lib/postfix/smtp pid 2954 killed by signal 11
          > >
          > > Thanks. Do you have a stack trace or core dump?
          >
          > Ralf sent be a stack trace captured via:
          >
          > http://www.postfix.org/DEBUG_README.html#screen
          >
          > problem fixed in the next snapshot. Nested macros need to be
          > careful with temporary variable names:
          >
          > Bug:
          >
          > #define foo(x) do { FOO *_t = x; bar(_t); /* code using _t */; }
          > #define bar(x) do { FOO *_t = x; /* code using _t */; }

          Technical nit: this bug is not specific to nested macros. Name
          collisions with temp variables may happen for other reasons. Just
          like macro names must be distinct, their temp variable names must
          be distinct, too.

          The solution that I adopted looks as follows:

          #define foo(x) do { FOO _foo_ = (x); do stuff with _foo_; } while (0)

          That is, use all or part of the macro name for each temporary
          variable. Then, append suffixes to the names if needed.

          Wietse
        Your message has been successfully submitted and would be delivered to recipients shortly.