libpthread and mutexes on HP-UX 11.00

[Maribeth Romeo]

I am porting c++ code from Linux to HP-UX 11.00 (32-bit). The problem that I'm having is that the program crashes (with a memory fault) whenever it tries to lock a mutex. I am compiling with
the -DPOSIX_C_SOURCE=199506L flag and also -D_POSIX_THREADS. I am compiling with gcc 3.4.2 and the OS is HP-UX 11.00. It has the latest QPK1100 loaded on it. Also, I've used ldd to make sure that the libraries are being loaded in the correct order. The order that I get back is:

/usr/lib/libc.2 => /usr/lib/libc.2
/usr/lib/libdld.2 => /usr/lib/libdld.2
/usr/lib/libc.2 => /usr/lib/libc.2
/usr/lib/libm.2 => /usr/lib/libm.2
/usr/lib/libpthread.1 => /usr/lib/libpthread.1

I read somewhere that on 32 bit machines, the order is reversed, so that libpthread is actually getting brought in first and not last.

Is there more information I need to get libpthread working correctly? Thanks.

[ranganath ramachandra]

libc should be last in link order.

if you link by calling the linker directly, your link line should have libpthread before libc . "ldd -y,pthread_mutex_lock a.out" (or "ldd -y a.out | grep pthread_mutex_lock")should show pthread_mutex_lock being resolved in libpthread and not libc.

if you link through gcc, you could perhaps check if gcc takes care of the link order, by turning on a verbose flag ('-v' ?).

[Maribeth Romeo]

When I turn on the -v option, I get:

Thread model: single

If this is a mutlithreaded app, why does it say single?

I also get information about g++. Is is:

../src/configure --enable-languages=c,c++ --prefix=/usr/local/pa20_32 --with-local-prefix=/usr/local/pa20_32 --with-gnu-as --with-as=/usr/local/pa20_32/bin/as --with-ld=/usr/ccs/bin/ld --disable-shared --disable-nls


Should it be using the linker in /usr/ccs/bin? I know this machine does not have the HP ANSI-C compiler... It has the non-ANSI compiler and gcc 3.4.2

[ranganath ramachandra]

the linker in /usr/ccs/bin/ld is correct -this calls /usr/ccs/lbin/ld32 which is the only linker for PA32.

the ldd listing you posted seems ok. can you post the stacktrace from the coredump ? if you cant expose proprietary code, you can post the top frames up to the point where your pthread call is made.

use gdb to get a stacktrace:
gdb /path/to/binary /path/to/core
(gdb) thread apply all bt

[Maribeth Romeo]

Here is the stack trace:

#0 0xc0aacb84 in pthread_mutex_trylock () from /usr/lib/libpthread.1
#1 0xc0aaca78 in pthread_mutex_trylock () from /usr/lib/libpthread.1
#2 0xc0209614 in __libc_mutex_trylock () from /usr/lib/libc.2
#3 0xc01e7588 in _findiop () from /usr/lib/libc.2
#4 0xc01f42c0 in fopen () from /usr/lib/libc.2
#5 0xc005a53c in ?? ()