Bug 315199 - vgcore file for threaded application does not show which thread crashed
Summary: vgcore file for threaded application does not show which thread crashed
Status: RESOLVED FIXED
Alias: None
Product: valgrind
Classification: Developer tools
Component: general (show other bugs)
Version: 3.9.0.SVN
Platform: Other Linux
: NOR normal
Target Milestone: ---
Assignee: Julian Seward
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2013-02-15 12:46 UTC by Matthias Schwarzott
Modified: 2014-07-23 07:55 UTC (History)
3 users (show)

See Also:
Latest Commit:
Version Fixed In:


Attachments
Refactor coredump writing of one thread: Extract function dump_one_thread (2.68 KB, patch)
2013-02-15 12:48 UTC, Matthias Schwarzott
Details
Move crashing thread to first position in coredump (699 bytes, patch)
2013-02-15 12:49 UTC, Matthias Schwarzott
Details
Refactor coredump writing of one thread: Extract function dump_one_thread (2.76 KB, patch)
2014-05-27 05:33 UTC, Matthias Schwarzott
Details
Move crashing thread to first position in coredump (660 bytes, patch)
2014-05-27 05:34 UTC, Matthias Schwarzott
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Matthias Schwarzott 2013-02-15 12:46:44 UTC
vgcore file should be changed, so gdb can directly display the thread that crashed.

Reproducible: Always

Steps to Reproduce:
1. Run crashing application
2. Run crashing application under valgrind
3. Open core and vgcore file in gdb and compare in which thread gdb is after start.

Actual Results:  
For kernel coredump, gdb shows thread 1 and this is where the crash was.
For vgcore this is not the crashing thread.


Expected Results:  
vgcore should also show the crashing thread in gdb.


Comparing output of gdb and "eu-readelf -n core": The first thread in the coredump is always the crashing one.

Valgrind should be changed accordingly.
Comment 1 Matthias Schwarzott 2013-02-15 12:48:42 UTC
Created attachment 77323 [details]
Refactor coredump writing of one thread: Extract function dump_one_thread
Comment 2 Matthias Schwarzott 2013-02-15 12:49:54 UTC
Created attachment 77324 [details]
Move crashing thread to first position in coredump

The attached patches change valgrind, so it writes the crashing thread first into the coredump.
Comment 3 Matthias Schwarzott 2014-05-27 05:33:34 UTC
Created attachment 86847 [details]
Refactor coredump writing of one thread: Extract function dump_one_thread

Update patches to apply to trunk, r13991
Comment 4 Matthias Schwarzott 2014-05-27 05:34:13 UTC
Created attachment 86848 [details]
Move crashing thread to first position in coredump
Comment 5 Matthias Schwarzott 2014-07-22 06:27:14 UTC
Is there a reason not to commit this improvement?

Btw. I don't know how to write a testcase for this.
Comment 6 Tom Hughes 2014-07-22 07:35:12 UTC
So you say "the first thread in the coredump is always the crashing one" but in fact you seem to be forcing it to be written last?

Is there some documentation somewhere that says how this should be done and how a debugger is supposed to know which is the faulting thread?
Comment 7 Matthias Schwarzott 2014-07-22 09:49:07 UTC
(In reply to Tom Hughes from comment #6)
> So you say "the first thread in the coredump is always the crashing one" but
> in fact you seem to be forcing it to be written last?
Well, the code adds it last to the list, but it is written in the reverse order.
Maybe I should add a comment to the code.

> 
> Is there some documentation somewhere that says how this should be done and
> how a debugger is supposed to know which is the faulting thread?
For this question I only know how it behaves.
I guess the gdb or binutils developers must know this.
But there seem to be no real specification of how core-files are thought to be used.
Comment 8 Florian Krohm 2014-07-22 09:55:18 UTC
(In reply to Matthias Schwarzott from comment #7)
>
> > Is there some documentation somewhere that says how this should be done and
> > how a debugger is supposed to know which is the faulting thread?

> For this question I only know how it behaves.
> I guess the gdb or binutils developers must know this.
> But there seem to be no real specification of how core-files are thought to
> be used.

From a usability point of view having the crashing thread listed first is a Good Thing IMHO.
Comment 9 Tom Hughes 2014-07-23 07:55:03 UTC
Committed (with a couple of comments added) as r14181.