re: posix semaphores not working under gdb

re: posix semaphores not working under gdb

[Kenny Simpson]

One thing that caused me some pain a while ago is the semaphore behavioral change in NPTL vs
LinuxThreads.  Under LinuxThreads, sem_wait will never return until the semaphore is aquired. 
With NPTL, sem_wait can return EINTR
... and DOES when gdb attaches.

The man pages in many distrubutions still have the old LinuxThreads documentation which explictly
states that sem_wait will not be affected by signals.

Hope this helps...
-Kenny



	
		
__________________________________ 
Yahoo! Mail - PC Magazine Editors' Choice 2005 
http://mail.yahoo.com

Re: posix semaphores not working under gdb

[Daniel Juan]

You are right Kenny,

if you look at the doc in NTPL:

man 3p sem_wait

The  sem_trywait()  and sem_wait() functions shall return zero if the
calling process successfully performed the semaphore lock operation on
the semaphore designated by sem.If the call was unsuccessful, the
state of the semaphore shall be unchanged, and the function shall
return a value of -1 and set errno to indicate the error.


If you look at Linuxthreads

man 3 sem_wait

The sem_wait and sem_getvalue functions always return 0.


Thanks

On 12/1/05, Kenny Simpson <theonetruekenny@yahoo.com> wrote:
> One thing that caused me some pain a while ago is the semaphore behavioral change in NPTL vs
> LinuxThreads.  Under LinuxThreads, sem_wait will never return until the semaphore is aquired.
> With NPTL, sem_wait can return EINTR
> ... and DOES when gdb attaches.
>
> The man pages in many distrubutions still have the old LinuxThreads documentation which explictly
> states that sem_wait will not be affected by signals.
>
> Hope this helps...
> -Kenny
>
>
>
>
>
> __________________________________
> Yahoo! Mail - PC Magazine Editors' Choice 2005
> http://mail.yahoo.com
>


--
Daniel Juan Boned
e-mail: daniel(dot)juan(at)gmail.com

Re: posix semaphores not working under gdb

[Jim Blandy]

Interesting: POSIX says, of thread_mutex_lock ( ),
pthread_mutex_trylock ( ), and pthread_mutex_unlock ( ):

34138      These functions shall not return an error code of [EINTR].

But of sem_wait ():
39299            The sem_trywait ( ) and sem_wait ( ) functions may fail if:
...
39301            [EINTR]             A signal interrupted this function.

posix semaphores not working under gdb

[Daniel Juan]

Hi,

I'm trying to debug a multithreaded application whith gdb ( using ddd
gui) and it seems that posix semaphores (sem_wait, sem_post) are not
working as expected when I run the app in the debugger.

Basically, the application has two semaphorized threads:
      - an openGL drawing one, and  a message processing one. (while
drawing, it's not permitted to process, and vice versa).

and it seems that, when I run the app whith the debugger, sometimes,
the processing thread unlocks the semaphore (and starts processing) 
while drawing is being done.

I don't know what I'm doing wrong.

Has someone experienced any similar issue?

# gdb --version
GNU gdb 6.3-debian

# g++ --version
g++ (GCC) 3.3.5 (Debian 1:3.3.5-13)

# uname -roms
Linux 2.6.11.7-mppe i686 GNU/Linux

Thanks a lot.

--
Daniel Juan Boned
e-mail: daniel(dot)juan(at)gmail.com

Re: posix semaphores not working under gdb

[Jim Blandy]

I'd be surprised if GDB were really disturbing the behavior of the
semaphores.  It's much more likely that GDB is disturbing the
real-time behavior of your program and showing up a bug in the locking
that your program, just by luck, never encounters when it's not being
debugged.

I don't know of any stories offhand of GDB breaking semaphores or mutexes.

Re: posix semaphores not working under gdb

[Daniel Juan]

Totally agree,

I don't think that GDB is the responsible of this strange behaviour, 
I only would like to know if someone experienced something similar
when debugging a multithreaded application. Because I can't, right
now, find any clue on whats wrong In the code.

On 11/30/05, Jim Blandy <jimb@red-bean.com> wrote:
> I'd be surprised if GDB were really disturbing the behavior of the
> semaphores.  It's much more likely that GDB is disturbing the
> real-time behavior of your program and showing up a bug in the locking
> that your program, just by luck, never encounters when it's not being
> debugged.
>
> I don't know of any stories offhand of GDB breaking semaphores or mutexes.
>


--
Daniel Juan Boned
e-mail: daniel(dot)juan(at)gmail.com