This is the mail archive of the
gdb-prs@sources.redhat.com
mailing list for the GDB project.
gdb/1515: 6.0 incomplete stack trace
- From: stuart_kemp at hotmail dot com
- To: gdb-gnats at sources dot redhat dot com
- Date: 16 Jan 2004 19:04:43 -0000
- Subject: gdb/1515: 6.0 incomplete stack trace
- Reply-to: stuart_kemp at hotmail dot com
>Number: 1515
>Category: gdb
>Synopsis: 6.0 incomplete stack trace
>Confidential: no
>Severity: serious
>Priority: medium
>Responsible: unassigned
>State: open
>Class: change-request
>Submitter-Id: net
>Arrival-Date: Fri Jan 16 19:08:01 UTC 2004
>Closed-Date:
>Last-Modified:
>Originator: stuart_kemp@hotmail.com
>Release: GNU gdb 6.0
>Organization:
>Environment:
Solaris 2.7
>Description:
I have a core from an application that called abort(). Using gdb 6.0 all I get from "where" are the functions after the abort() call. Using gdb 5.3 or gdb 4.18 I get a complete stack-trace. i.e. following is the gdb 6.0 output:
(gdb) bt
#0 0xff329dc0 in __sigprocmask () from /usr/lib/libthread.so.1
#1 0xff31f3cc in _resetsig () from /usr/lib/libthread.so.1
#2 0xff31eb88 in _sigon () from /usr/lib/libthread.so.1
#3 0xff32195c in _thrp_kill () from /usr/lib/libthread.so.1
(gdb)
>How-To-Repeat:
I cannot send you the exe nor core, since this is from our internal apps. However, if you want me to try rebuild and rerun with certain code-changes, I can try help debug that way.
>Fix:
>Release-Note:
>Audit-Trail:
>Unformatted: