RE: [libunwind] libunwind segv with gcc 2.96 programs run on Redhat EL3 with GLIBC 2.3.2

[Harrow, Jerry]

>>-----Original Message-----
>>From: David Mosberger [mailto:address@hidden
>>Sent: Friday, February 13, 2004 10:00 PM
>>To: Harrow, Jerry
>>Cc: address@hidden
>>Subject: Re: [libunwind] libunwind segv with gcc 2.96 programs run on
>>Redhat EL3 with GLIBC 2.3.2
>>Thanks for providing a test-case that reproduces the problem.  I
>>looked into it and it turns out it's a stupid typo in libunwind.  The

The patch works wonders.  Thanks for looking into it.  I really
appreciate it.

>>Jerry, just to be clear: even so, libunwind doesn't (and really
>>cannot) guarantee that local unwinding with bad unwind info won't
>>cause a crash (remote unwinding doesn't have this issue).  So if you
>>want to be super-safe, you may want to install a SIGSEGV handler.

I understand.  I don't think we have any other methods to provide call
stacks though.  The callstack collection can be turned off by a user of
our tool, so we will just release note the problem and the workarounds
(turn off callstack collection or re-compile with a newer compiler).  

Coincidentally, right after I got past the failures with libunwind, I
discovered we are also getting a SEGV in pthread_exit() which apparently
has problems unwinding gcc 2.93-compiled application stacks also.  

        Program received signal SIGSEGV, Segmentation fault.
        [Switching to Thread 2305843009230485712 (zombie)]
        0x20000000008a1a41 in _Unwind_GetBSP () from /lib/libgcc_s.so.1

Likewise, recompiling with a newer gcc fixes this problem also.
Obviously, upgrading to a newer gcc is strongly "suggested" for all :-).

Thanks again.

-Jer