Prev: Any way to archive the same using regexp transport in versions2.3+
Next: TLS not being advertised or not running?
From: "Steve" on 21 Jul 2010 17:53

-------- Original-Nachricht --------
> Datum: Wed, 21 Jul 2010 22:23:06 +0200
> Von: Kai Krakow <hurikhan77+postfix(a)googlemail.com>
> An: Postfix users <postfix-users(a)postfix.org>
> Betreff: Re: postfix/local segfaults

> 2010/7/21 Wietse Venema <wietse(a)porcupine.org>:
> > That would be a compiler bug, possibly compiler version dependent.
>
> Yep, I'm sure it is. The postfix ebuild from gentoo contains some
> evidence that hardened gcc 3.4 may be problematic. In case you are
> interested, follow up bug report:
> http://bugs.gentoo.org/show_bug.cgi?id=328375
>
Ohh boy. That is stuff I wrote 5 years ago.


> --
> Regards,
> Kai Krakow
> http://hurikhan77.wordpress.com/

--
Neu: GMX De-Mail - Einfach wie E-Mail, sicher wie ein Brief!
Jetzt De-Mail-Adresse reservieren: http://portal.gmx.net/de/go/demail

From: Victor Duchovni on 21 Jul 2010 23:22
On Wed, Jul 21, 2010 at 11:16:04PM +0200, Bas Mevissen wrote:

> Can you try what happens if you replace at
>
> typedef struct LOCAL_STATE {
> int level; /* nesting level, for logging */
> DELIVER_ATTR msg_attr; /* message/recipient attributes */
> DELIVER_REQUEST *request; /* as from queue manager */
> } LOCAL_STATE;
>
>
> the first line with:
>
> typedef struct local_state {
>
> in virtual.h and same for DELIVER_ATTR and DELIVER_REQUEST?
>
> The difference is that the symbol LOCAL_STATE is now only used once.
> Most coding standards forbid to define a symbol more than once.

The local(8) and virtual(8) servers are separately compiled
programs (the latter being a stripped down version of the former).
The header files in question are not used in the same compilation
unit, and so this suggestion is not productive.

--
Viktor.

From: Bas Mevissen on 22 Jul 2010 02:21
On 07/22/2010 05:22 AM, Victor Duchovni wrote:
> On Wed, Jul 21, 2010 at 11:16:04PM +0200, Bas Mevissen wrote:
>
>
>> Can you try what happens if you replace at
>>
>> typedef struct LOCAL_STATE {
>> int level; /* nesting level, for logging */
>> DELIVER_ATTR msg_attr; /* message/recipient attributes */
>> DELIVER_REQUEST *request; /* as from queue manager */
>> } LOCAL_STATE;
>>
>>
>> the first line with:
>>
>> typedef struct local_state {
>>
>> in virtual.h and same for DELIVER_ATTR and DELIVER_REQUEST?
>>
>> The difference is that the symbol LOCAL_STATE is now only used once.
>> Most coding standards forbid to define a symbol more than once.
>>
> The local(8) and virtual(8) servers are separately compiled
> programs (the latter being a stripped down version of the former).
> The header files in question are not used in the same compilation
> unit, and so this suggestion is not productive.
>
>
Ah, even more fun. Using a different typedef with the same name all over
the source tree.
I would never recommend someone to have a global symbol redefined in the
same source tree. Even if it are different applications as in this case.

Anyway, my remarks is still valid if you change file local.h instead of
virtual.h.

--
Bas

From: Kai Krakow on 22 Jul 2010 02:58
Bas,

why should that make a difference if it was already proven that
changing the optimization level of the compiler fixes the issue, and
that it is probably a special corner case of hardened gcc3.4? I
suppose it has to do with it's stack protecting techniques etc.

2010/7/22 Bas Mevissen <abuse(a)basmevissen.nl>:
> On 07/22/2010 05:22 AM, Victor Duchovni wrote:
>> On Wed, Jul 21, 2010 at 11:16:04PM +0200, Bas Mevissen wrote:
>>
>>
>>> Can you try what happens if you replace at
>>>
>>> typedef struct LOCAL_STATE {
>>>     int level;                /* nesting level, for logging */
>>>     DELIVER_ATTR msg_attr;    /* message/recipient attributes */
>>>     DELIVER_REQUEST *request; /* as from queue manager */
>>> } LOCAL_STATE;
>>>
>>>
>>> the first line with:
>>>
>>> typedef struct local_state {
>>>
>>> in virtual.h and same for DELIVER_ATTR and DELIVER_REQUEST?
>>>
>>> The difference is that the symbol LOCAL_STATE is now only used once.
>>> Most coding standards forbid to define a symbol more than once.
>>>
>> The local(8) and virtual(8) servers are separately compiled
>> programs (the latter being a stripped down version of the former).
>> The header files in question are not used in the same compilation
>> unit, and so this suggestion is not productive.
>>
>>
> Ah, even more fun. Using a different typedef with the same name all over
> the source tree.
> I would never recommend someone to have a global symbol redefined in the
> same source tree. Even if it are different applications as in this case.
>
> Anyway, my remarks is still valid if you change file local.h instead of
> virtual.h.

--
Regards,
Kai Krakow
http://hurikhan77.wordpress.com/

From: Wietse Venema on 22 Jul 2010 08:21
Kai Krakow:
> Bas,
>
> why should that make a difference if it was already proven that
> changing the optimization level of the compiler fixes the issue, and
> that it is probably a special corner case of hardened gcc3.4? I
> suppose it has to do with it's stack protecting techniques etc.

That is possible.

Postfix passes a structure by value as a function argument, meaning
that it will take up a larger than usual amount of stack space.

This may violate assumptions about stack usage that are made by
some stack "protection" mechanisms.

The pass-by-value structure is part of a Postfix safety mechanism,
and therefore I am not inclined to change it to work around buggy
compiler features.

Wietse

First  |  Prev  |  Next  |  Last
Pages: 1 2 3
Prev: Any way to archive the same using regexp transport in versions2.3+
Next: TLS not being advertised or not running?