This is the mail archive of the
gdb-prs@sources.redhat.com
mailing list for the GDB project.
Re: threads/1585: pthread_create generates notify to semaphore when run under gdb
- From: chastain at sourceware dot org
- To: bbr at lampreynetworks dot com, chastain at sourceware dot org, gdb-prs at sources dot redhat dot com, nobody at sources dot redhat dot com
- Date: 24 Jul 2004 04:03:04 -0000
- Subject: Re: threads/1585: pthread_create generates notify to semaphore when run under gdb
- Reply-to: chastain at sourceware dot org, bbr at lampreynetworks dot com, chastain at sourceware dot org, gdb-prs at sources dot redhat dot com, nobody at sources dot redhat dot com, gdb-gnats at sources dot redhat dot com
Synopsis: pthread_create generates notify to semaphore when run under gdb
Responsible-Changed-From-To: unassigned->chastain
Responsible-Changed-By: chastain
Responsible-Changed-When: Sat Jul 24 04:03:04 2004
Responsible-Changed-Why:
I'll take it.
State-Changed-From-To: open->feedback
State-Changed-By: chastain
State-Changed-When: Sat Jul 24 04:03:04 2004
State-Changed-Why:
This is a side effect of the implementation of thread support in gdb.
In order to track threads, gdb puts hidden breakpoints on the library functions for thread creation and thread destruction. Unfortunately, when any thread takes a breakpoint, all threads stop -- and any other thread that is inside a system call may return prematurely from that system call.
It's unfortunate that the system call returns differently under gdb than standalone. However, both behaviors conform to Single Unix Specification version 3 for sem_wait. The Spec allows sem_wait to return with EINTR if a signal arrives; the signal is the breakpoint trap on thread creation from the other thread.
Your program should check the return value from each system call.
See the section "Thread Stops" in the gdb manual (gdb 6.1 or later) for more info.
Michael C
GDB QA Guy
http://sources.redhat.com/cgi-bin/gnatsweb.pl?cmd=view%20audit-trail&database=gdb&pr=1585