Project Home
Project Home		 Documents
Documents		 Wiki
Wiki		 Discussion Forums
Discussions		 Project Information
Project Info
QNX Operating System/Discussion/OSTech/SIGDEADLK clarification/List of Posts
Forum Topic - SIGDEADLK clarification: (8 Items)
   
Update
Claudio Gregorio
08/18/2009 3:22 PM
post36218
SIGDEADLK clarification   
Hallo folks,

I have a question about SIGDEADLK. I got sporadically this signal with QNX 6.3.2 and a multithread application. 

Looking into the Web and into the QNX documentation I did not completely understand when exactly the kernel deliver such
 signal...
Moreover, what it is really strange is that I'm getting (sporadically) such signal once I try to lock a static allocated
 mutex (initialized with PTHREAD_MUTEX_INITIALIZER). This mutex is also never destroyed (no call to 
pthread_mutex_destroy)...

Thanks for your help,

-Claudio
Colin Burgess(deleted)
08/18/2009 3:46 PM
post36226
Re: SIGDEADLK clarification   
See http://www.qnx.com/developers/docs/6.4.1/neutrino/sys_arch/ipc.html#id20

Cheers,

Colin

Claudio Gregorio wrote:
> Hallo folks,
> 
> I have a question about SIGDEADLK. I got sporadically this signal with QNX 6.3.2 and a multithread application. 
> 
> Looking into the Web and into the QNX documentation I did not completely understand when exactly the kernel deliver 
such signal...
> Moreover, what it is really strange is that I'm getting (sporadically) such signal once I try to lock a static 
allocated mutex (initialized with PTHREAD_MUTEX_INITIALIZER). This mutex is also never destroyed (no call to 
pthread_mutex_destroy)...
> 
> Thanks for your help,
> 
> -Claudio
> 
> 
> 
> 
> _______________________________________________
> 
> OSTech
> http://community.qnx.com/sf/go/post36218
> 

-- 
cburgess@qnx.com
Claudio Gregorio
08/18/2009 3:58 PM
post36228
Re: SIGDEADLK clarification   
Thanks Colin,

I already read that doc but it is unclear to me the exact meaning of:

"...and if the conditions that would cause the kernel to deliver the event occur, then the kernel delivers a SIGDEADLK 
instead."

If I understand correctly the only condition should be if the mutex enters the DEAD state, BUT how can I get this state 
with a static mutex initialized with PTHREAD_MUTEX_INITIALIZER and never destroyed?
Are there any other case where I can get this event?

Many thanks for your help,

-Claudio
Loic Domaigne
08/24/2009 3:09 AM
post36484
Re: SIGDEADLK clarification   
Hello, 

is there a way to found out which thread / call issued the SIGDEADLK signal? 
Is SIGDEADLK only caused by munmap()? If not, what are the possible functions causing SIGDEADLK to be raised? 

Thanks in advance,
Loïc
Colin Burgess(deleted)
08/24/2009 10:09 AM
post36513
Re: SIGDEADLK clarification   
Can you capture it in a kernel trace?

Claudio Gregorio wrote:
> Thanks Colin,
> 
> I already read that doc but it is unclear to me the exact meaning of:
> 
> "...and if the conditions that would cause the kernel to deliver the event occur, then the kernel delivers a SIGDEADLK
 instead."
> 
> If I understand correctly the only condition should be if the mutex enters the DEAD state, BUT how can I get this 
state with a static mutex initialized with PTHREAD_MUTEX_INITIALIZER and never destroyed?
> Are there any other case where I can get this event?
> 
> Many thanks for your help,
> 
> -Claudio
> 
> 
> 
> _______________________________________________
> 
> OSTech
> http://community.qnx.com/sf/go/post36228
> 

-- 
cburgess@qnx.com
Loic Domaigne
08/25/2009 2:20 AM
post36593
Re: SIGDEADLK clarification   
Hi Colin

> Can you capture it in a kernel trace?

That's extremely difficult for the target application, unfortunately. 

Thanks,
Loïc (on behalf of Claudio)
Colin Burgess(deleted)
08/25/2009 9:36 AM
post36618
Re: SIGDEADLK clarification   
Is the static mutex in a shared lib?  The SIGDEADLK can only be generated by an unmap killing the mutex.

Claudio Gregorio wrote:
> Thanks Colin,
> 
> I already read that doc but it is unclear to me the exact meaning of:
> 
> "...and if the conditions that would cause the kernel to deliver the event occur, then the kernel delivers a SIGDEADLK
 instead."
> 
> If I understand correctly the only condition should be if the mutex enters the DEAD state, BUT how can I get this 
state with a static mutex initialized with PTHREAD_MUTEX_INITIALIZER and never destroyed?
> Are there any other case where I can get this event?
> 
> Many thanks for your help,
> 
> -Claudio
> 
> 
> 
> _______________________________________________
> 
> OSTech
> http://community.qnx.com/sf/go/post36228
> 

-- 
cburgess@qnx.com
Claudio Gregorio
08/31/2009 3:03 AM
post36925
Re: SIGDEADLK clarification   
Hello Colin,

the mutex is part of a static library, declared as static and initialized through PTHREAD_MUTEX_INITIALIZER.

-Claudio

Return


  A subsidiary of BlackBerry             All content ©2004-2013, QNX Software Systems