[Linux-ia64] gdb problem unwinding abort in signal

[Linux-ia64] gdb problem unwinding abort in signal

[Mario Smarduch]

When our application aborts in the signal handler (no altstack
is setup) the stack backtrace  discontinues at the signal
handler.

(gdb) where
#0  0x20000000000a6342 in kill () at soinit.c:56
#1  0x20000000000a61f0 in raise (sig=6) at ../sysdeps/posix/raise.c:27
#2  0x20000000000a8a70 in abort () at ../sysdeps/generic/abort.c:88
#3  0x4000000000000910 in sig_report_and_die ()


Manually unwinding the stack shows  the rp set
to ia64_sigtramp(). The privilaged
gate page simplifies allot of things,  but it poses a problem
to our software because we send events for
all signals of importance, and count on the core dump
to capture the full call trace prior to and including the
signal - gdb displays this full backtrace on all other
architectures we run on.

If this is the problem how does one get around it
besides manually unwinding the stack?

- mario.

Re: [Linux-ia64] gdb problem unwinding abort in signal

[David Mosberger]

>>>>> On Fri, 11 Apr 2003 13:17:38 -0500, Mario Smarduch <cms063@email.mot.com> said:

  Mario> When our application aborts in the signal handler (no
  Mario> altstack is setup) the stack backtrace discontinues at the
  Mario> signal handler.

  Mario> (gdb) where #0 0x20000000000a6342 in kill () at soinit.c:56
  Mario> #1 0x20000000000a61f0 in raise (sig=6) at
  Mario> ../sysdeps/posix/raise.c:27 #2 0x20000000000a8a70 in abort ()
  Mario> at ../sysdeps/generic/abort.c:88 #3 0x4000000000000910 in
  Mario> sig_report_and_die ()


  Mario> Manually unwinding the stack shows the rp set to
  Mario> ia64_sigtramp(). The privilaged gate page simplifies allot of
  Mario> things, but it poses a problem to our software because we
  Mario> send events for all signals of importance, and count on the
  Mario> core dump to capture the full call trace prior to and
  Mario> including the signal - gdb displays this full backtrace on
  Mario> all other architectures we run on.

  Mario> If this is the problem how does one get around it besides
  Mario> manually unwinding the stack?

There is a gdb patch in the works that will use libunwind for
backtracing purposes.  Unwinding across signal handlers will work just
fine then (at least with reasonably recent kernels).  An old
(alpha-quality) snapshot of such a gdb is at:

	ftp://ftp.hpl.hp.com/pub/linux-ia64/ugdb-ia64-020531.tar.gz

and someone from Red Hat is now working on updating the gdb patch for
libunwind v0.9 (and hopefully on getting it into the official gdb
tree).

	--david

Re: [Linux-ia64] gdb problem unwinding abort in signal

[Mario Smarduch]

David Mosberger wrote:

> >>>>> On Fri, 11 Apr 2003 13:17:38 -0500, Mario Smarduch <cms063@email.mot.com> said:
>
>   Mario> When our application aborts in the signal handler (no
>   Mario> altstack is setup) the stack backtrace discontinues at the
>   Mario> signal handler.
>
>   Mario> (gdb) where #0 0x20000000000a6342 in kill () at soinit.c:56
>   Mario> #1 0x20000000000a61f0 in raise (sig=6) at
>   Mario> ../sysdeps/posix/raise.c:27 #2 0x20000000000a8a70 in abort ()
>   Mario> at ../sysdeps/generic/abort.c:88 #3 0x4000000000000910 in
>   Mario> sig_report_and_die ()
>
>   Mario> Manually unwinding the stack shows the rp set to
>   Mario> ia64_sigtramp(). The privilaged gate page simplifies allot of
>   Mario> things, but it poses a problem to our software because we
>   Mario> send events for all signals of importance, and count on the
>   Mario> core dump to capture the full call trace prior to and
>   Mario> including the signal - gdb displays this full backtrace on
>   Mario> all other architectures we run on.
>
>   Mario> If this is the problem how does one get around it besides
>   Mario> manually unwinding the stack?
>
> There is a gdb patch in the works that will use libunwind for
> backtracing purposes.  Unwinding across signal handlers will work just
> fine then (at least with reasonably recent kernels).  An old
> (alpha-quality) snapshot of such a gdb is at:
>
>         ftp://ftp.hpl.hp.com/pub/linux-ia64/ugdb-ia64-020531.tar.gz
>
> and someone from Red Hat is now working on updating the gdb patch for
> libunwind v0.9 (and hopefully on getting it into the official gdb
> tree).
>
>         --david

Great we'll try it, currently we're running  debian
distro 2.4.20-cgl-1.1-mckinley-smp.

thks,
    Mario.