pthread_cond_wait crashes on HPUX10.20

[Arthur Prosso]

Hello.

I use gcc 3.2.2 on HPUX10.20 and DCE thread library (libcma is used). It was configured with the following switches:

Reading specs from /usr/local/lib/gcc-lib/hppa1.1-hp-hpux10.20/3.2.2/specs
Configured with: ../gcc-3.2.2/configure --enable-shared --disable-threads --enable-languages=c,c++,f77
Thread model: single
gcc version 3.2.2


The following piece of code crashes:

=============================================
#include
#include

int main(int argc, char* argv[])
{
pthread_mutex_t * hMutex = new pthread_mutex_t;
pthread_cond_t * hEvent = new pthread_cond_t;


// Mutex Initialization
pthread_mutexattr_t attr;

int ret1, ret2, ret3;
if( (ret1=::pthread_mutexattr_create(&attr)) != 0 || (ret2=::pthread_mutexattr_setkind_np(&attr, MUTEX_RECURSIVE_NP)) != 0 ||
(ret3 = ::pthread_mutex_init(hMutex, attr)) != 0 )
{
printf( "Ret1 = %d, ret2 = %d, ret3 = %d\n", ret1, ret2, ret3);
exit(0);
}

::pthread_mutexattr_delete(&attr);

// Event Initialization
pthread_condattr_t condattr;
::pthread_condattr_create(&condattr);

if( ::pthread_cond_init(hEvent, condattr) != 0 )
printf ("Event Initialization failed\n");

::pthread_condattr_delete(&condattr);

pthread_mutex_lock(hMutex);

// inifinte
printf ("Wait infinitely ...\n");
pthread_cond_wait(hEvent, hMutex);

return 0;
}
==============================================

The program output is:
Wait infinitely ...
Segmentation fault (core dumped)


Notes:
1)When compiling the program with aCC, the same code produces:
Wait infinitely ..
Bus error (core dumped)

2) Using pthread_cond_timedwait instead of pthread_cond_wait does not
crash, it returns -1 and sets errno to EAGAIN, indicating that the wait time has elapsed

3) The same piece of code works fine on LINUX
(of course, some pthread function names were modified correspondingly for LINUX)


Question: Any ideas what could cause a crash of
pthread_cond_wait?

Thank you in advance,
Arthur Prosso

[Umapathy S]

Arthur,
I dont see any problem in the code. Did you a get a backtrace on the core. Post the backtrace.

I always linked libdce.a instead of libcma.a. Can you try linking with libdce.a and get back with the results.

HTH,
Umapathy

[Arthur Prosso]

Umapathy.
Thank you for reply.

The core examination adds too few info:

Core was generated by `test'.
Program terminated with signal 11, Segmentation fault.
#0 0xc1bef274 in ??

> backtrace
#0 0xc1bef274 in ?? ()
Cannot access memory at address 0xc1bef118

I tried to link with libdce.a - with the same result, but!!!

I tried to run pthread_cond_wait in a separate thread and it worked. Very strange. I don't see any reason why pthread_cond_wait shoud not work in a single threaded app.

Maybe now you will have any more ideas?
Thank you,
Arthur

[Umapathy S]

Arthur,

Man page of pthread_mutexattr_setkind_np says like this.


Never use a recursive mutex with condition variables because the
implicit unlock performed for a pthread_cond_wait() or
pthread_cond_timedwait() might not actually release the mutex. In that
case, no other thread can satisfy the condition of the predicate.

This routine is a new primitive.


So, the thread is actually timing out and dumps with a SIGBUS for data corruption. I changed the program to C, compiled and ran. It dumped core. I tried to view the core and gdb itself dumped. I dont know the reason.

HTH,
Umapathy

[Adam J Markiewicz]

Hi Arthur

I have it nailed out for you.

It appeares the problem is that some initialisation of cma internal structuresess that authors decided that there is no point to use synchronisation, while you have only one thread.

Try to start a new thread before calling pthread_mutex_lock().
Just in case - I did it for you and it worked.

However I can also say that according to man pages using recursive mutexes with conditional variables is not the good idea.

Also - if you live C++ way move the initialisation part to the constructors, and deallocation in destructors - this is the meaning of their existance. Frankly - that's what I really did in my code. And of course you don't have to allocate mutex and conditional_variable dynamicaly - you can use automatic variables, just like you did with attributes. But thats not the point.

Good luck
Adam