Re: [libunwind] SIGSEGV trying unw_get_reg on Linux_IA64

[David Mosberger]

>>>>> On Tue, 15 Feb 2005 15:49:36 +0100, "Mensing, Joerg" <address@hidden> 
>>>>> said:

  Joerg> I know the glibc unwinder is buggy and not ABI conform, but i
  Joerg> am loading DLL's compiled with the 'original' unwinder that
  Joerg> throw exceptions which are caught in the main
  Joerg> executable. Without this trick exception unwinding is not
  Joerg> handled correctly...

Can you provide a minimal test-case that fails?  It should _not_ be
necessary to link against libgcc_eh for unwinding-purposes.

  Joerg> I found a small problem during dumping registers in my stack
  Joerg> backtrace code pinned to down to

  Joerg>        unw_get_reg(&cursor, registerIndex, &regValue);

  Joerg> For registerIndex 140 (alias nat12) in src/ia64/unwind_i.h
  Joerg> line 96 a NULL pointer is dereferenced leading to SIGSEGV:

  Joerg> I modified my libunwind source locally to work around it:

  Joerg> $ diff unwind_i.h_ori unwind_i.h_fixed
  Joerg> 96c96,99
  Joerg> <       *nat_bitnr = reg - UNW_IA64_NAT;
  Joerg> ---
  Joerg> >       if ( nat_bitnr )
  Joerg> >       {
  Joerg> >         *nat_bitnr = reg - UNW_IA64_NAT;
  Joerg> >       }

Hmmh, this shouldn't be necessary.  linux_scatch_loc() should never be
invoked with nat_bitnr==NULL when accessing a NaT register.
Unfortunately, the backtrace isn't very helpful since the line-number
info is wrong.  Can you compile with GCC v3.4 and redo the test?  That
should cure the line-number problems.

  Joerg> 2) Before i call the stack backtrace code, i set an emergency
  Joerg> hook by using sigsetjmp() to protect the running database
  Joerg> server. I do not expect a SIGSEGV really, but you never know
  Joerg> (see problem 1). The 'setsetjmp()' is currently the orginal
  Joerg> one, that comes with the glibc. It seems to do really strange
  Joerg> things with the stack frame. If a single step behind
  Joerg> sigsetjmp() call the gdb suddenly reports.

That sounds like a gdb problem.  If you provide a minimal test-case, I
can confirm.

  Joerg> 3) Do you have any more news about the missing glibc
  Joerg> unwinding info which does not allow to unwind beyond system
  Joerg> call on linux_x86_64?

I don't think that issue affects x86-64.  This bug-report:

  Joerg> http://sources.redhat.com/bugzilla/show_bug.cgi?id=595

is for x86.

  Joerg> i see no other way to get stack backtrace in a signal handler
  Joerg> for linux_x86_64 without it....

Did you mean to refer to this bug:

 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18748
 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18749

?

If so, you're right: it doesn't look good.  It appears that nobody
cares.  Kind of strange, because, as you say, it makes it impossible
to reliably get a backtrace out of a signal-handler.

Personally, I don't care to fight this battle.  I assume that
eventually there will be enough complaints that GCC will get fixed.

  Joerg> 4) I would make me much more happy not to link with
  Joerg> -lgcc_eh.... Maybe i missed that discussion, but will (or
  Joerg> has) your unwinder (or at least a compatible implementation)
  Joerg> replace (or replaced) glibc's buggy unwinder in a standard
  Joerg> distribution (i.e. Plans for LSB 3.0) ? I could forward it as
  Joerg> an issue to LSB 3.0 group if you like!

See my comment to the first question.  You shouldn't need gcc_eh for
unwinding-purposes.

Thanks,

        --david