sievec core dumps when hitting 'address' or 'envelope'

Scott Adkins adkinss at ohio.edu
Mon Aug 30 11:33:10 EDT 2004


Yeah, I concluded something similar as well, the problem only exists on
64 bit platforms...

Scott

--On Sunday, August 29, 2004 11:22 PM -0600 Michael Loftis 
<mloftis at wgops.com> wrote:

> Probably has to do with 64 bit alignment and pointers versus 32 bit
> alignment and pointers.  by reordering the int/pointer pair the union
> becomes not so much a union in the sense that may be meant for it.
> didn't look into it deeply at all myself, but it would ppear that the
> machine code/variable space for each of the compiled versions of those
> mis-ordered unions is quite different on 64 bit platforms.
>
> --On Monday, August 30, 2004 00:42 -0400 Scott Adkins <adkinss at ohio.edu>
> wrote:
>
>> We ran into a problem on Tru64 where the sieve compiler was core dumping
>> if it tried to compile a script that used 'address' or 'envelope' in it.
>> For example, the following script would core dump sievec:
>>
>>   if address :contains "To" "jshmoe at nowhere.com" {
>>       stop;
>>   }
>>
>> Changing 'address' to 'header' would work just fine.
>>
>> I tracked it down to a header file, tree.h.  Basically, there is a union
>> defined inside the 'Test' structure that itself defines a few structures
>> that would share the same memory space (so to speak... if you understand
>> C programming, then you should understand what unions are).  The problem
>> is that two of the structures defined many of the same variables as each
>> other, but in different orders...
>>
>> For example, the first structure in the union declares A, B, then C, but
>> the second structure in the union declares A, C, then B.
>>
>> This shouldn't normally be a problem, but on Tru64 5.x, it certainly is.
>> I am not sure if it is a weirdness with 'cc', or if it is something
>> deeper.
>> The code compiles and without warnings, but it core dumps at runtime.
>>
>> Simply changing the order in one structure or the other to match solves
>> the problem nicely.
>>
>> This could very well be related to the following bug:
>>
>>   <https://bugzilla.andrew.cmu.edu/show_bug.cgi?id=2476>
>>
>> I submitted a patch, which I will include here, that should fix it.  It
>> is a *very* small patch :)
>>
>> Scott
>> --
>>  +----------------------------------------------------------------------
>>  -+ Scott W. Adkins                http://www.cns.ohiou.edu/~sadkins/
>>    UNIX Systems Engineer                  mailto:adkinss at ohio.edu ICQ
>>         7626282                 Work (740)593-9478 Fax (740)593-1944
>>  +----------------------------------------------------------------------
>>  -+ PGP Public Key available at http://www.cns.ohiou.edu/~sadkins/pgp/
>
>
>
> --
> Undocumented Features quote of the moment...
> "It's not the one bullet with your name on it that you
> have to worry about; it's the twenty thousand-odd rounds
> labeled `occupant.'"
>    --Murphy's Laws of Combat
>
> ---
> Cyrus Home Page: http://asg.web.cmu.edu/cyrus
> Cyrus Wiki/FAQ: http://cyruswiki.andrew.cmu.edu
> List Archives/Info: http://asg.web.cmu.edu/cyrus/mailing-list.html



-- 
 +-----------------------------------------------------------------------+
      Scott W. Adkins                http://www.cns.ohiou.edu/~sadkins/
   UNIX Systems Engineer                  mailto:adkinss at ohio.edu
        ICQ 7626282                 Work (740)593-9478 Fax (740)593-1944
 +-----------------------------------------------------------------------+
     PGP Public Key available at http://www.cns.ohiou.edu/~sadkins/pgp/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 231 bytes
Desc: not available
Url : https://lists.andrew.cmu.edu/mailman/private/info-cyrus/attachments/20040830/2f44d033/attachment.bin


More information about the Info-cyrus mailing list