Bug 1024504

Summary: Please make it easier to find the backtrace of the crashing thread
Product: [Fedora] Fedora Reporter: Miloslav Trmač <mitr>
Component: gdbAssignee: Jan Kratochvil <jan.kratochvil>
Status: CLOSED ERRATA QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: 22CC: abrt-devel-list, gbenson, jan.kratochvil, jfilak, mmilata, palves, pmuldoon, sergiodj, tromey
Target Milestone: ---   
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: gdb-7.9.1-16.fc22 Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2015-06-19 14:45:02 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Description Miloslav Trmač 2013-10-29 19:52:56 UTC
Description of problem:
Looking at https://bugzilla.redhat.com/attachment.cgi?id=696390 in https://bugzilla.redhat.com/show_bug.cgi?id=910262:

> Program terminated with signal 11, Segmentation fault.
> #0  js::PropertyTable::search (this=0x3b0813f960 <js_ArrayClass>, id=253538485472, adding=false) at jsscope.cpp:308
> 308	    stored = *spp;
>
> Thread 5 (Thread 0x7f08977b6700 (LWP 831)):
> #0  0x0000003adf8e998d in poll () at ../sysdeps/unix/syscall-template.S:81
> No locals.
...

This doesn't tell me which thread has crashed, and after the relevant single line starts with a backtrace of a probably irrelevant thread.

Please consider:
1) indicating which thread crashed (... terminated with signal 11 in thread 1)
2) listing the backtrace of the crashing thread before backtraces of any other threads

Comment 1 Fedora End Of Life 2015-01-09 20:24:06 UTC
This message is a notice that Fedora 19 is now at end of life. Fedora 
has stopped maintaining and issuing updates for Fedora 19. It is 
Fedora's policy to close all bug reports from releases that are no 
longer maintained. Approximately 4 (four) weeks from now this bug will
be closed as EOL if it remains open with a Fedora 'version' of '19'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version.

Thank you for reporting this issue and we are sorry that we were not 
able to fix it before Fedora 19 is end of life. If you would still like 
to see this bug fixed and are able to reproduce it against a later version 
of Fedora, you are encouraged  change the 'version' to a later Fedora 
version prior this bug is closed as described in the policy above.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events. Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

Comment 2 Jakub Filak 2015-01-09 21:55:12 UTC
Re-assigning from satyr to gdb because backtraces that ABRT attaches to bugzilla bugs are generated by gdb.

Comment 3 Jan Kratochvil 2015-01-11 20:02:07 UTC
At least as a workaround ABRT could just send also "-ex thread" before "-ex bt" so that the current thread is printed.  GDB could print it in non-interactive mode although (1) I am not sure if ABRT runs it in a way GDB detects it as non-interactive and (2) I am not sure if GDB upstream accepts different output in non-interactive mode than in interactive mode. (3) For interactive mode the thread identification seems redundant to me as one is already switched to the crashing thread.

Comment 4 Jan Kratochvil 2015-01-15 18:34:46 UTC
[patch] Sort threads for thread apply all (bt)
https://sourceware.org/ml/gdb-patches/2015-01/msg00433.html

Comment 5 Jakub Filak 2015-01-19 07:10:32 UTC
(In reply to Jan Kratochvil from comment #4)
> [patch] Sort threads for thread apply all (bt)
> https://sourceware.org/ml/gdb-patches/2015-01/msg00433.html

Jan, I am impressed! The "-asc" argument for "thread apply all" is fabulous. Thanks!

Comment 6 Jan Kratochvil 2015-01-23 16:52:32 UTC
It is now upstreamed but what should be backported into which Fedora versions so that it can be used by ABRT?

I do not think this message should be backported to F-20/F-21 as it may break compatibility (despite CLI parsing is discouraged apps do it, incl. ABRT):
  [Current thread is 1 (Thread 0x7fcbe28fe700 (LWP 15453))]

The new parameter "-ascending" to "thread apply all" could be backported even to F-20/F-21, will ABRT use it there?  Obviously using "-ascending" with current/older GDB errors out:
  Undefined command: "-ascending".  Try "help".

Comment 7 Jakub Filak 2015-01-26 13:24:50 UTC
Jan, we are currently overwhelmed by work on F22, so I hope we will not upset anybody, if just push your patches to Rawhide. But if you have time, backport  the patches to F21 and I will release an updated ABRT packages in few months.

Comment 8 Jaroslav Reznik 2015-03-03 16:56:37 UTC
This bug appears to have been reported against 'rawhide' during the Fedora 22 development cycle.
Changing version to '22'.

More information and reason for this action is here:
https://fedoraproject.org/wiki/Fedora_Program_Management/HouseKeeping/Fedora22

Comment 9 Jakub Filak 2015-06-19 14:37:23 UTC
Upstream commit https://github.com/abrt/abrt/commit/500a863ce4f7307e6a093b2063284434e4c3aa9d adds the argument '-ascending' to abrt, however, we have to teach the retrace sever to use that argument too:
https://github.com/abrt/retrace-server/issues/77

Comment 10 Jan Kratochvil 2015-06-19 14:45:02 UTC
comment 9 will be in: gdb-7.9.1-16.fc22
Displaying of the current thread (thread 1) after loading a core file is already in F-23+ (I do not plan an F-22 backport).

Comment 11 Fedora Update System 2015-06-19 15:21:52 UTC
gdb-7.9.1-16.fc22 has been submitted as an update for Fedora 22.
https://admin.fedoraproject.org/updates/gdb-7.9.1-16.fc22

Comment 12 Fedora Update System 2015-06-25 08:24:38 UTC
gdb-7.9.1-16.fc22 has been pushed to the Fedora 22 stable repository.  If problems still persist, please make note of it in this bug report.