Bradshaw, James | 22 Oct 19:47 2008

gdb/gdbserver 6.8 question: info threads

Hi,

 

Sorry if this has asked and answered, but I have not been able to find this issue in the archives.

 

I’m running a trivial multithreaded program on a Redhat  5.1  linux system, kernel 2.6.18, and I’m seeing some unexpected behavior with gdbserver. Here’s the source:

 

#include <stdio.h>

#include <stdlib.h>

#include <pthread.h>

 

void *print_message_function( void *ptr );

 

main()

{

     pthread_t thread1, thread2;

     char *message1 = "Thread 1";

     char *message2 = "Thread 2";

     int  iret1, iret2;

 

    /* Create independent threads each of which will execute function */

 

     iret1 = pthread_create( &thread1, NULL, print_message_function, (void*) message1);

     iret2 = pthread_create( &thread2, NULL, print_message_function, (void*) message2);

 

     /* Wait till threads are complete before main continues. Unless we  */

     /* wait we run the risk of executing an exit which will terminate   */

     /* the process and all threads before the threads have completed.   */

 

     pthread_join( thread1, NULL);

     pthread_join( thread2, NULL);

 

     printf("Thread 1 returns: %d\n",iret1);

     printf("Thread 2 returns: %d\n",iret2);

     exit(0);

}

 

void *print_message_function( void *ptr )

{

     char *message;

     message = (char *) ptr;

     printf("%s \n", message);

}

 

 

Under gdb 6.8 it all seems to work fine—in particular new threads are reported as they are  created and “info threads” works:

 

[jbradsha-linux](jbradsha)294$ /export/jbradsha/workdir/gdb/gdb-6.8/gdb/gdb pthread

GNU gdb 6.8

Copyright (C) 2008 Free Software Foundation, Inc.

License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>

This is free software: you are free to change and redistribute it.

There is NO WARRANTY, to the extent permitted by law.  Type "show copying"

and "show warranty" for details.

This GDB was configured as "i686-pc-linux-gnu"...

(gdb) b pthread.c:10

Breakpoint 1 at 0x80484a5: file pthread.c, line 10.

(gdb) n

The program is not being run.

(gdb) c

The program is not being run.

(gdb) r

Starting program: /home/rtrsvcs/jbradsha/sandbox/pthread

[Thread debugging using libthread_db enabled]

[New Thread 0xb7fd26c0 (LWP 13381)]

[Switching to Thread 0xb7fd26c0 (LWP 13381)]

 

Breakpoint 1, main () at pthread.c:10

10           char *message1 = "Thread 1";

(gdb) info threads

* 1 Thread 0xb7fd26c0 (LWP 13381)  main () at pthread.c:10

(gdb) n

11           char *message2 = "Thread 2";

(gdb) n

16           iret1 = pthread_create( &thread1, NULL, print_message_function, (void*) message1);

(gdb) info threads

* 1 Thread 0xb7fd26c0 (LWP 13381)  main () at pthread.c:16

(gdb) n

[New Thread 0xb7fd1b90 (LWP 13386)]

17           iret2 = pthread_create( &thread2, NULL, print_message_function, (void*) message2);

(gdb) info threads

  2 Thread 0xb7fd1b90 (LWP 13386)  0x0081afc8 in clone () from /lib/libc.so.6

* 1 Thread 0xb7fd26c0 (LWP 13381)  main () at pthread.c:17

(gdb) c

Continuing.

Thread 1

[New Thread 0xb75d0b90 (LWP 13400)]

[Thread 0xb7fd1b90 (LWP 13386) exited]

Thread 2

[Thread 0xb75d0b90 (LWP 13400) exited]

Thread 1 returns: 0

Thread 2 returns: 0

 

Program exited normally.

(gdb)

 

Now when I run the program under gdbserver and connect with gdb (both on the localhost) I find that threads don’t seem to be reported correctly to gdb:

 

(gdb) target remote localhost:4500

`system-supplied DSO at 0xcb0000' has disappeared; keeping its symbols.

Remote debugging using localhost:4500

[New Thread 13460]

0x0072c810 in _start () from /lib/ld-linux.so.2

(gdb) c

Continuing.

 

Breakpoint 1, main () at pthread.c:10

10           char *message1 = "Thread 1";

(gdb) info threads

* 1 Thread 13460  main () at pthread.c:10

(gdb) n

11           char *message2 = "Thread 2";

(gdb) n

16           iret1 = pthread_create( &thread1, NULL, print_message_function, (void*) message1);

(gdb) n

17           iret2 = pthread_create( &thread2, NULL, print_message_function, (void*) message2);

(gdb) n

23           pthread_join( thread1, NULL);

(gdb) info threads

* 1 Thread 13460  main () at pthread.c:23

(gdb) c

Continuing.

 

Program exited normally.

(gdb)

 

However, the console output clearly indicates that the program runs correctly:

 

[jbradsha-linux](jbradsha)257$ /export/jbradsha/workdir/gdb/gdb-6.8/gdb/gdbserver/gdbserver :4500 pthread

Process pthread created; pid = 13460

Listening on port 4500

Remote debugging from host 127.0.0.1

Thread 1

Thread 2

Thread 1 returns: 0

Thread 2 returns: 0

 

Child exited with retcode = 0

 

Child exited with status 0

GDBserver exiting

[jbradsha-linux](jbradsha)258$

 

Here are the shared libraries I’m using with gdb/gdbserver:

 

[jbradsha-linux](jbradsha)295$ ldd /export/jbradsha/workdir/gdb/gdb-6.8/gdb/gdb

        linux-gate.so.1 =>  (0x00c55000)

        libncurses.so.5 => /usr/lib/libncurses.so.5 (0x02db3000)

        libm.so.6 => /lib/libm.so.6 (0x0088f000)

        libexpat.so.0 => /lib/libexpat.so.0 (0x00a92000)

        libdl.so.2 => /lib/libdl.so.2 (0x008b8000)

        libc.so.6 => /lib/libc.so.6 (0x0074d000)

        /lib/ld-linux.so.2 (0x0072c000)

 

[jbradsha-linux](jbradsha)259$ ldd /export/jbradsha/workdir/gdb/gdb-6.8/gdb/gdbserver/gdbserver

        linux-gate.so.1 =>  (0x00126000)

        libthread_db.so.1 => /lib/libthread_db.so.1 (0x0088f000)

        libc.so.6 => /lib/libc.so.6 (0x0074d000)

        /lib/ld-linux.so.2 (0x0072c000)

 

Can someone tell me if this is a gdbserver bug or just an error on my part, and, if so, how to fix it so that gdbserver correctly reports thread information to gdb?

 

Thanks very much.

 

Ted Bradshaw

 

 

Roman Green | 23 Oct 19:18 2008
Picon

Accessing DSO binary code when debugging core dump

Hello,
 
Is it possible in GDB to view a shared library (DSO) machine code when debugging a core dump? I am running GDB 6.8 on 32-bit ArchLinux (kernel 2.6.27).
 
When I specify the main executable (with file command) and then do sharedlibrary, I receive the following warning (what does it mean by the way?):
Can't read pathname for load map: I/O error.
 
Debug symbols for DSOs are loaded successfully and I can inspect thread call stacks, local vars etc. But an attempt to access any DSO function binary code (disassemble, x etc) fails wth error:
Cannot access memory at address <...>
 
However I have no problem accessing binary code in the main executable!
 
Any help would be appreciated.
 
 
 
Regards,
Roman

Gmane