cancel
Showing results for 
Search instead for 
Did you mean: 

Problem with -lpthread

 
Highlighted
Occasional Contributor

Problem with -lpthread

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




7 REPLIES 7
Highlighted
New Member

Re: Problem with -lpthread

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.
New Member

Re: Problem with -lpthread

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

Re: Problem with -lpthread

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 ...

Highlighted
New Member

Re: Problem with -lpthread

Have you used -mt option?

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



Highlighted
Frequent Advisor

Re: Problem with -lpthread

Hello,

Which IC version you are using ?

Arun
Highlighted
New Member

Re: Problem with -lpthread

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

Re: Problem with -lpthread

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.