Re: gdb and multi-threaded applications.

Kevin,

On Feb 26, 12:38pm, jjs wrote:

quoted

Thanks for your reply the other day, I have tried taking the gdb-000222
snapshot from the ftp site and compiled it, but I am getting the same
behaviour as I was with 4.17.0.14, which unfortunately I did not fully
describe in my original message. I am seeing the described behaviour with
'info threads' but also when I run my program under gdb, it hangs when
trying to create a new thread via a call to pthread_create. It works as
expected outside the debugger, creating the thread and continuing.

I have tried attaching gdb to the gdb process that is hanging and get the
following stack trace:

#0  0x15c64c0 in __syscall_rt_sigsuspend () at soinit.c:59
#1  0x15c51f0 in __sigsuspend (set=0x19da444)

Would it be possible for you to print out the contents of set at this
point?  (Go "up" a frame and do "print *set".)

quoted

    at ../sysdeps/unix/sysv/linux/sigsuspend.c:48
#2  0x184aa88 in linux_child_wait (pid=-1, rpid=0x7fffe0f0,
status=0x7fffe0f4)
    at linux-thread.c:1338

(gdb) p *set
$2 = {__val = {0 <repeats 32 times>}}

And I'd like to see what linux_threads_block_mask is at this point too.

(gdb) p linuxthreads_block_mask
$3 = {__val = {0 <repeats 32 times>}}

quoted

#3  0x184ad14 in linuxthreads_wait (pid=-1, ourstatus=0x7fffe150)
    at linux-thread.c:1415
#4  0x18316e4 in wait_for_inferior () at infrun.c:1261

I have seen this backtrace before.  For a time, I was seeing hangs
under certain circumstances when debugging single threaded
applications too.  The problem was that the SIGCHLD signal was being
blocked.  This is why I want to know the signal mask is which is being
passed to sigsuspend().

quoted

I am running with kernel 2.2.6-15apmac, which came with the linuxppc-1999
distribution.

We're running the same kernels at least.

quoted

Any assistance you can give me will be gratefully received.

Are you running a proprietary applicaton?  If not, it may be useful at
some point for me to get a copy of it and try to reproduce the problems
you're seeing myself.

Unfortunately, I am running a proprietory application.

In the interim, it may be useful for you to try out the threaded
program testsuite/gdb.threads/linux-dp which is (obviously) in the gdb
testsuite.  Here's part of a sample run when I try it.  (Note:  If you
do "make check" from the gdb directory, all of the programs will be
built and the test suite will be run.  After the testsuite finishes
running, all of the programs are built and you can try running them
yourself.)

   [kev@arroyo testsuite]$ ../gdb gdb.threads/linux-dp
   GNU gdb 20000204
   Copyright 1998 Free Software Foundation, Inc.
   GDB is free software, covered by the GNU General Public License, and

you are

   welcome to change it and/or distribute copies of it under certain

conditions.

   Type "show copying" to see the conditions.
   There is absolutely no warranty for GDB.  Type "show warranty" for

details.

   This GDB was configured as "powerpc-unknown-linux-gnu"...
   (gdb) b 187
   Breakpoint 1 at 0x10000d7c: file

/ocotillo1/kev/sourceware/src/gdb/testsuite/gdb.threads/linux-dp.c, line
187.

   (gdb) r
   Starting program:

/home/kev/sourceware-gdb-bld/gdb/testsuite/gdb.threads/linux-dp

   Breakpoint 1, main (argc=1, argv=0x7ffffd04)
at /ocotillo1/kev/sourceware/src/gdb/testsuite/gdb.threads/linux-dp.c:187
   187         for (i = 0; i < num_philosophers; i++)
   (gdb) info thread
   (gdb) n
   189             numbers[i] = i;
   (gdb) n
   191             pthread_create (&philosophers[i], &ta, philosopher,

&numbers[i]);

   (gdb) s
   [New Thread 32622 (manager thread)]
   [New Thread 32621 (initial thread)]
   [New Thread 32623]
   187         for (i = 0; i < num_philosophers; i++)
   (gdb) info thread
     3 Thread 32623  0xfe094c0 in __syscall_rt_sigsuspend () at

soinit.c:59

   * 2 Thread 32621 (initial thread)  main (argc=1, argv=0x7ffffd04)
at /ocotillo1/kev/sourceware/src/gdb/testsuite/gdb.threads/linux-dp.c:187
     1 Thread 32622 (manager thread)  0xfe08178 in kill () at soinit.c:59
   (gdb) print num_philosophers
   $1 = 5
   (gdb) n
     _ 0 _
     ! 0 _
   189             numbers[i] = i;
   (gdb)
   191             pthread_create (&philosophers[i], &ta, philosopher,

&numbers[i]);

   (gdb)
   [New Thread 32624]
  _ 1 _
  ! 1 _
  ! 1 !
  _ 1 _
   187         for (i = 0; i < num_philosophers; i++)

The thing to notice in the above run is that we make it through several
calls of pthread_create().  (If I would've sent you the rest of my trace
you'd see that it makes it through all five calls successfully.)

I tried running linux-dp under gdb and it works exactly as you  describe, so
there is no fundamental problem with gdb debugging a program that calls
pthread_create.

Also... I doubt that it'll matter, but I've fixed a few bugs in the last
several days.  (I'm now seeing only 14 testsuite failures.)  You may wish
to download a newer version.

One last thing... could you do "rpm -q -f /lib/libpthread-0.8.so" and tell
me what the output is?  Here's what happens when I try it:

   [kev@arroyo kev]$ rpm -q -f /lib/libpthread-0.8.so
   glibc-2.1.1-6c

This gave the same for me as it did you.

Kevin

--
Kevin Buettner
kev@primenet.com, kevinb@redhat.com

I hope this helps. If there is any other information I can give you please
don't hesitate to ask.

Cheers, Jerry.


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/