[Bug c++/21240] New: Deadlock (pthread) in signal handler

[szehau at gmail dot com]

When a process is interrupted by a signal, a mutex lock (eg. when calling
free(), malloc() or other C functions) might be already acquired after the
interruption. Therefore, when the program calls a C function, the program goes
into a race condition and is waiting for a mutex to be unlocked. My questions 
are: 

1. Is this a bug in g++?
2. Is there any way to check whether there is a mutex was already locked (for
the above case) in the program's signal handler? or any compler option that I
can apply to avoid the deadlock?


For your information, I am using

Thread model: posix
gcc version 3.2 20020903 (Red Hat Linux 8.0 3.2-7)


Thanks
Low Sze Hau

-- 
   Summary: Deadlock (pthread) in signal handler
   Product: gcc
   Version: 3.2.2
Status: UNCONFIRMED
  Severity: normal
  Priority: P1
 Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: szehau at gmail dot com
CC: gcc-bugs at gcc dot gnu dot org,szehau at gmail dot com


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21240

[Bug c++/21240] Deadlock (pthread) in signal handler

[szehau at gmail dot com]

--- Additional Comments From szehau at gmail dot com  2005-04-28 02:06 
---
(In reply to comment #1)
> Do you have a testcase?
> On second thought pthreads and mutex lockes and signals are out of the scope
of a compiler, If this is 
> a bug, this is a glibc bug but I really doubt it.

In this case, I need to know whether there is a fucntion that I can use to check
whether a mutex is currently locked.

For example:



void alarmHdl (int sig) {

// Check whether a mutext is lock here

bool locked = someFunctionToCheckMutexIsLocked ();

if (!locked) {
// other tasks here that might call malloc or free
}

}


int main () {

signal (SIGALRM, alarmHdl);

alarm (5);

// a big loop

for (;;) {
// tasks here might call malloc or free
}

return 0;
}

Thanks

-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21240