multithreaded core files

multithreaded core files

[David Carlton]

One of my coworkers is looking at a core file from a multithreaded
program.  (x86 Linux.)  In this situation, GDB only prints a backtrace
from the thread that actually seg faulted; he'd like to see what other
threads were doing at the time.

I assume there's no easy way to fix that, but he had the idea of
looking through the memory to find out where the other threads' stacks
are.  Not completely impossible - we know some of the functions to
expect in the other threads' backtraces, so we can come up with some
addresses to look for.

If we can find those other stacks, is there any way that we can try to
convince GDB to print out backtraces for them?  And even give us local
variable information?

Thanks,
David Carlton
david.carlton@sun.com

Re: multithreaded core files

[Daniel Jacobowitz]

On Thu, Jan 25, 2007 at 11:40:42AM -0800, David Carlton wrote:
> One of my coworkers is looking at a core file from a multithreaded
> program.  (x86 Linux.)  In this situation, GDB only prints a backtrace
> from the thread that actually seg faulted; he'd like to see what other
> threads were doing at the time.

It should already print all the backtraces.  If it doesn't, the usual
explanation is that you are using a broken kernel version which does
not save registers for every thread.  Many 2.4 kernels fit that
description.

-- 
Daniel Jacobowitz
CodeSourcery

Re: multithreaded core files

[Neo]

Daniel Jacobowitz wrote:
> On Thu, Jan 25, 2007 at 11:40:42AM -0800, David Carlton wrote:
>   
>> One of my coworkers is looking at a core file from a multithreaded
>> program.  (x86 Linux.)  In this situation, GDB only prints a backtrace
>> from the thread that actually seg faulted; he'd like to see what other
>> threads were doing at the time.
>>     
>
> It should already print all the backtraces.  
Daniel,

Could you point me to the code that does this job inside GDB?

Thanks,
Neo
> If it doesn't, the usual
> explanation is that you are using a broken kernel version which does
> not save registers for every thread.  Many 2.4 kernels fit that
> description.
>
>   


-- 
I would remember that if researchers were not ambitious
probably today we haven't the technology we are using!

Re: multithreaded core files

[Daniel Jacobowitz]

On Thu, Jan 25, 2007 at 01:54:05PM -0600, Neo wrote:
> Could you point me to the code that does this job inside GDB?

The corefile code will load one set of registers for each thread.
The code is scattered around, e.g. in corefile.c and in bfd to create
the .reg "sections".

-- 
Daniel Jacobowitz
CodeSourcery

Re: multithreaded core files

[David Carlton]

On Thu, 25 Jan 2007 14:48:40 -0500, Daniel Jacobowitz <drow@false.org> said:
> On Thu, Jan 25, 2007 at 11:40:42AM -0800, David Carlton wrote:

>> One of my coworkers is looking at a core file from a multithreaded
>> program.  (x86 Linux.)  In this situation, GDB only prints a backtrace
>> from the thread that actually seg faulted; he'd like to see what other
>> threads were doing at the time.

> It should already print all the backtraces.  If it doesn't, the usual
> explanation is that you are using a broken kernel version which does
> not save registers for every thread.  Many 2.4 kernels fit that
> description.

Interesting.  I guess I got stuck in my mind from the 2.4 days that
this doesn't work; checking a recent core file, I see the information
I want.  I'll check with my coworker to see what the vintage is of his
core file...

David Carlton
david.carlton@sun.com