Problem with -lpthread

Madhuwati — Tue, 11 May 2004 07:14:54 GMT

Hi All,

I am facing a weird problem on HP 11.23 PI PA debug OS. A C client dumps core as follows:

assertion failed: hdr.priv_valid == PRIVATE_VALID,
file: /ux/core/libs/threadslibs/src/common/pthreads/tls_supp.c, line: 108
Return Pointer is 0xc032691b
Process ID is 9491
Asserting Thread is 0x0
Segmentation fault (core dumped)

What does this signify?

On tracing through gdb the error is emitted when dlopen() is called. The C client is loading a shared C++ library.

The o/p of trace thru gdb:
gdb) n
51 handle = (void *) dlopen(VX_REMOTEINFO_LIBNAME, RTLD_LAZY);
(gdb) s
assertion failed: hdr.priv_valid == PRIVATE_VALID, file:
/ux/core/libs/threadslibs/src/common/pthreads/tls_supp.c, line: 108
Return Pointer is 0x7ae9391b
Process ID is 13557
Asserting Thread is 0x0

Program received signal SIGSEGV, Segmentation fault.
0x7ae77098 in __pth_vassert (a=0x7ae01420 "hdr.priv_valid == PRIVATE_VALID",
f=0x7ae01358 "/ux/core/libs/threadslibs/src/common/pthreads/tls_supp.c",
l=108, rp=0x7ae9391b "\3017\227", self=0x0,
lck_msg=0x0, real_rp=0x0) at
/ux/core/libs/threadslibs/src/common/pthreads/debug.c:559
559 /ux/core/libs/threadslibs/src/common/pthreads/debug.c: No such
file or directory.

(gdb) where
#0 0xc030a098 in __pth_vassert (a=0xc0294420 "hdr.priv_valid == PRIVATE_VALID", f=0xc0294358
"/ux/core/libs/threadslibs/src/common/pthreads/tls_supp.c", l=108, rp=0xc032691b "\3017\227",
self=0x0, lck_msg=0x0, real_rp=0x0) at /ux/core/libs/threadslibs/src/common/pthreads/debug.c:559
#1 0xc032695c in __PTHREAD_SELF_D (real_self=0x7af8ac00, real_id=1)
at /ux/core/libs/threadslibs/src/common/pthreads/tls_supp.c:108
#2 0xc02cc8d0 in ENTER_PTHREAD_LIBRARY_FUNC () at /ux/core/libs/threadslibs/src/common/pthreads/pthread.c:8685
#3 0xc030f9ac in __pthread_dump_lib ( msg=0x7b022918 "assertion failed: hdr.priv_valid == PRIVATE_VALID, file:
/ux/core/libs/threadslibs/src/common/pthreads/tls_supp.c, line: 108\nReturn Pointer is 0xc032691b\nProcess ID is 9322\nAsserting Thread is 0x0\n",
self=0x0) from /usr/lib/libpthread.1
#4 0xc030a740 in __pth_vassert (a=0xc0294420 "hdr.priv_valid == PRIVATE_VALID", f=0xc0294358
"/ux/core/libs/threadslibs/src/common/pthreads/tls_supp.c", l=108, rp=0xc032691b "\3017\227", self=0x0, lck_msg=0x0, real_rp=0x0) at
/ux/core/libs/threadslibs/src/common/pthreads/debug.c:644
#5 0xc032695c in __PTHREAD_SELF_D (real_self=0x7af8ac00, real_id=1)
at /ux/core/libs/threadslibs/src/common/pthreads/tls_supp.c:108
#6 0xc02ef0a0 in __owns_NO_spinlock () at /ux/core/libs/threadslibs/src/common/pthreads/spin.c:913
#7 0xc02e2f6c in __pthread_mutex_lock (mutex=0x7b044398) at /ux/core/libs/threadslibs/src/common/pthreads/mutex.c:3906
#8 0xc0221ee0 in __thread_mutex_lock+0x70 () from /usr/lib/libc.2
#9 0xc01998c4 in real_malloc+0x94 () from /usr/lib/libc.2
#10 0xc019787c in _malloc+0x654 () from /usr/lib/libc.2
#11 0xc019d67c in malloc+0x18c () from /usr/lib/libc.2
#12 0xc04a5658 in operator new+0x40 () from /usr/lib/libCsup.2
#13 0xc2f7cb6c in __sinit_Args_C+0x5d4 () from /usr/lib/libvrascmd.sl
#14 0xc04a5550 in __shlInit+0x88 () from /usr/lib/libCsup.2
#15 0xc2f685c8 in _shlInit+0x20 () from /usr/lib/libvrascmd.sl
#16 0xc04a4e88 in __shlinit+0xac () from /usr/lib/libCsup.2
#17 0xc0030da0 in ?? ()
#18 0xc030a088 in __pth_vassert (a=0x4 "", f=0x7f7f0a34 "VFEN\177\177\n4", l=4, rp=0x7f7f0a34 "VFEN\177\177\n4", self=0x5646454e, lck_msg=0x384

, real_rp=0x384

) at /ux/core/libs/threadslibs/src/common/pthreads/debug.c:558

Shared library links to:
dynamic /usr/lib/libstd.2
dynamic /usr/lib/libstream.2
dynamic /usr/lib/libCsup.2
dynamic /usr/lib/libm.2
dynamic /usr/lib/libcl.2
dynamic /usr/lib/libdld.2
dynamic /usr/lib/libpthread.1

C client links to:
dynamic /usr/lib/libstd.2
dynamic /usr/lib/libstream.2
dynamic /usr/lib/libCsup.2
dynamic /usr/lib/libm.2
dynamic /usr/lib/libcl.2
dynamic /usr/lib/libdld.2
dynamic /usr/lib/libpthread.1
dynamic /usr/lib/libc.2

By trial and error I found a workaround for this as to remove -lpthread from the C client.
But this does not seem like a clean solution. Has anyone come across such a problem? What is the reason for the coredump and what would be a correct solution for the same ?

Thanks in advance.
- Madhu

Re: Problem with -lpthread

kim_43 — Tue, 25 May 2004 03:16:46 GMT

Don't put -lc ahead of -lpthread on the link line.
(Also, when you use -mt option, aCC takes care of automatically adding the -lpthread at the right place).

HP-UX 11.23 only.

Re: Problem with -lpthread

kim_43 — Tue, 25 May 2004 03:19:15 GMT

pls remove -lc from the makefile and try it.
Maybe it works...

Re: Problem with -lpthread

Madhuwati_1 — Tue, 25 May 2004 03:48:28 GMT

There is no -lc before -lpthread.

For the C client the LDLIBS are:
-lstd -lstream -lCsup -lm -lcl -l: libdld.sl -lpthread

The C++ client does not link to libc.sl ...

Re: Problem with -lpthread

kim_43 — Tue, 01 Jun 2004 04:07:04 GMT

Have you used -mt option?

If you not use -mt option, compiler use libc automatically.
this causes several SIGBUS.

Re: Problem with -lpthread

Arunvijai.S — Thu, 03 Jun 2004 05:04:40 GMT

Hello,

Which IC version you are using ?

Arun

Re: Problem with -lpthread

Madhu_14 — Thu, 03 Jun 2004 05:20:19 GMT

I tried using IC versions ... 11.23-i80_LR and 11.23-ic71l,VM

Re: Problem with -lpthread

Manish_21 — Thu, 03 Jun 2004 05:51:35 GMT

You can get this error only if there is a memory corruption. Error mesg means that the TLS list is corrupted and has been accidently overwritten by the applcation. Please check your application to see for the overflows or memory corruption.

topic Re: Problem with -lpthread in Operating System - HP-UX

Problem with -lpthread

Re: Problem with -lpthread

Re: Problem with -lpthread

Re: Problem with -lpthread

Re: Problem with -lpthread

Re: Problem with -lpthread

Re: Problem with -lpthread

Re: Problem with -lpthread