This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
Re: [patch] Sort threads for thread apply all (bt)
- From: Doug Evans <dje at google dot com>
- To: Jan Kratochvil <jan dot kratochvil at redhat dot com>
- Cc: gdb-patches <gdb-patches at sourceware dot org>
- Date: Thu, 15 Jan 2015 11:29:07 -0800
- Subject: Re: [patch] Sort threads for thread apply all (bt)
- Authentication-results: sourceware.org; auth=none
- References: <20150115183316 dot GA16405 at host2 dot jankratochvil dot net>
On Thu, Jan 15, 2015 at 10:33 AM, Jan Kratochvil
<jan.kratochvil@redhat.com> wrote:
> Hi,
>
> downstream Fedora request:
> Please make it easier to find the backtrace of the crashing thread
> https://bugzilla.redhat.com/show_bug.cgi?id=1024504
>
> Currently after loading a core file GDB prints:
>
> Core was generated by `./threadcrash1'.
> Program terminated with signal SIGSEGV, Segmentation fault.
> #0 0x000000000040062f in start (arg=0x0) at threadcrash1.c:8
> 8 *(volatile int *)0=0;
> (gdb) _
>
> there is nowhere seen which of the threads had crashed. In reality GDB always
> numbers that thread as #1 and it is the current thread that time. But after
> dumping all the info into a file for later analysis it is no longer obvious.
> 'thread apply all bt' even puts the thread #1 to the _end_ of the output!!!
>
> Should GDB always print after loading a core file what "thread" command would
> print?
> [Current thread is 1 (Thread 0x7fcbe28fe700 (LWP 15453))]
Sounds reasonable to me.
Though there is the concern to not even talk about threads if there are "none".
So maybe only print that if there is more than one thread?
> Or should the "thread" output be printed only in non-interactive mode?
>
> Or something different?
>
> Or is the current behavior OK as is and the tools calling GDB in batch mode
> should indicate the thread #1 on their own?
>
> ------------------------------------------------------------------------------
>
> I find maybe as good enough and with no risk of UI change flamewar to just
> sort the threads by their number. Currently they are printed as they happen
> in the internal GDB list which has no advantage. Printing thread #1 as the
> first one with assumed 'thread apply all bt' (after the core file is loaded)
> should make the complaint resolved I guess.
>
> No regressions on {x86_64,x86_64-m32,i686}-fedora22pre-linux-gnu.
No objection to sorting the list, but if thread #1 is the important one,
then a concern could be it'll have scrolled off the screen (such a
concern has been voiced in another thread in another context),
and if not lost (say it's in an emacs buffer) one would still have
to scroll back to see it.
So one *could* still want #1 to be last.
Do we want an option to choose the sort direction?
[I wouldn't make it a global parameter, just an option to
thread apply.]