[Gdb] GDB multithread coredump only shows valid state for one thread?

[Charles Lindsay]

Hi,

I'm not sure whether this properly belongs on the GDB, NPTL or Linux mailing lists.

I have a multi-threaded application which generates a core file.
GDB apparently understands the core file well enough to know that there are two threads involved,
and interpret the state of the one thread (i.e. "backtrace" and "info reg" works fine)
but doesn't seem to be able to determine the register set/stack of the other thread.
(see below for example GDB output)

If I run the application under GDB, I can breakpoint and see the state of all threads without difficulty.

GNU gdb 6.5.0.20060626-cvs
Linux 2.6.13-1.1532_FC4 SMP i686 i686 i386 GNU/Linux
gcc version 4.0.2 20051125 (Red Hat 4.0.2-8)
libc-2.3.6.so

Is this problem familiar to anyone?  Have you any suggestions?
Is there some configuration directive I need to enable?
Can you tell me how to determine whether the core file just doesn't contain the register values for the "other" thread,
or whether GDB doesn't know how to extract them? 

Thanks.

Objdump seems to see multiple register sets (if I understand it, although I don't know how to interpret them):

objdump -h core.1853 

core.1853:     file format elf32-i386

Sections:
Idx Name          Size      VMA       LMA       File off  Algn
  0 note0         00000cf8  00000000  00000000  000004d4  2**0
                  CONTENTS, READONLY
  1 .reg/1864     00000044  00000000  00000000  00000530  2**2     <--- registers for one thread?
                  CONTENTS
  2 .reg          00000044  00000000  00000000  00000530  2**2
                  CONTENTS
  3 .auxv         00000090  00000000  00000000  00000b70  2**2
                  CONTENTS
  4 .reg2/1864    0000006c  00000000  00000000  00000c14  2**2
                  CONTENTS
  5 .reg2         0000006c  00000000  00000000  00000c14  2**2
                  CONTENTS
  6 .reg-xfp/1864 00000200  00000000  00000000  00000c94  2**2
                  CONTENTS
  7 .reg-xfp      00000200  00000000  00000000  00000c94  2**2
                  CONTENTS
  8 .reg/1853     00000044  00000000  00000000  00000ef0  2**2     <--- registers for the other thread?
                  CONTENTS
  9 .reg2/1853    0000006c  00000000  00000000  00000f4c  2**2
                  CONTENTS
 10 .reg-xfp/1853 00000200  00000000  00000000  00000fcc  2**2
                  CONTENTS
 11 load1         00000000  00195000  00000000  00002000  2**12
                  CONTENTS, ALLOC, LOAD, READONLY, CODE
 12 load2         00001000  001b8000  00000000  00002000  2**12
                  CONTENTS, ALLOC, LOAD, READONLY
 13 load3         00001000  001b9000  00000000  00003000  2**12
                  CONTENTS, ALLOC, LOAD
<etc>

<GDB output follows>:

(gdb) info thread
  2 process 1853  0x00000246 in ?? ()
* 1 process 1864  0x0808cda9 in app_mon_handle_get (bname=0x96a6168 "/app/check", bname_parts=0x96a6190, data="" 
    resp_bindings=0x96a5e38) at layerManager.cc:1924
(gdb) info reg
eax            0x4      4
ecx            0x0      0
edx            0x9672008        157753352
ebx            0x44e    1102
esp            0xb6a1ee90       0xb6a1ee90
ebp            0xb6a1eef8       0xb6a1eef8
esi            0x362    866
edi            0x8234ad1        136530641
eip            0x808cda9        0x808cda9 <app_monhandle_get(char const*, tstr_array const*, void*, bn_binding_array*)+1825>
eflags         0x10202  [ IF RF ]
cs             0x73     115
ss             0x7b     123
ds             0x7b     123
es             0xc010007b       -1072693125
fs             0x0      0
gs             0x33     51
(gdb) thread 2
[Switching to thread 2 (process 1853)]#0  0x00000246 in ?? ()
(gdb) info reg
eax            0xc010007b       -1072693125
ecx            0x9687f68        157843304
edx            0x2deff4 3010548
ebx            0x40     64
esp            0x0      0x0                         <--- presumably invalid?
ebp            0x7b     0x7b
esi            0xbfe36678       -1075616136
edi            0xfffffffc       -4
eip            0x246    0x246
eflags         0x7b     [ CF #3 AF #5 ZF ]
cs             0x6658   26200
ss             0x0      0
ds             0xa8     168
es             0x7410   29712
fs             0x0      0
gs             0x33     51
(gdb) bt
#0  0x00000246 in ?? ()
Cannot access memory at address 0x0
(gdb)