SOLVED
Is this an application you compiled/built ? I see a similar problem reported here which I could reproduce very easily:
http://community.hpe.com/t5/Languages-and-Scripting/received-SIGSEGV-while-executing-an-exe/td-p/4785614
In this case, using gcc, the problem goes away when the program is built linked with libpthread. If you're compiling and linking with aCC, the recommended way is to use the "-mt" compiler flag.
If this is not an application you built yourself, you might have to contact the vendor about it.
In the post you linked, Dennis seems to suggest that the thread stack size be increased.
--
ranga
[i work for hpe]
curioser, etc
Here's another report of a crash in ENTER_PTHREAD_LIBRARY_FUNC:
http://community.hpe.com/t5/Languages-and-Scripting/Problem-with-lpthread/td-p/3273067
Whether a stack overflow is happening, you can try to figure out from examining the disassembly in ENTER_PTHREAD_LIBRARY_FUNC up to the point where SIGSEGV is received. Doing that with the testcase previously mentioned seems to show that there was a problem in trying to access thread local storage (TLS) - this seems to match with the last post on the thread I have linked above in this post. Also, building that previous testcase with "-lc" before "-lpthread" reproduces the crash. So, there is some vague indication that the problem may be caused by bad link order or memory corruption.
For Oracle or HPE to be able to triage/debug the problem, you can help by providing a packcore tarball created with gdb. Launch the application from within gdb, use the "dump" command to generate a core dump once this SIGSEGV occurs (make sure that it is this instance of SIGSEGV). With this done, get gdb to load the core file with the "core-file" command and then use the "packcore" command to create the packcore tarball.
bash-2.05b# gdb testJNI ... (gdb) r Starting program: /tmp/ranga/itrc1/testJNI Program received signal SIGSEGV, Segmentation fault si_code: 2 - SEGV_ACCERR - Invalid Permissions for object. 0x9fffffffebe39f60:1 in ENTER_PTHREAD_LIBRARY_FUNC+0x61 () from /usr/lib/hpux64/libpthread.so.1 (gdb) dump Dumping core to the core file core.28689 (gdb) core-file core.28689 A program is being debugged already. Kill it? (y or n) y Core was generated by `testJNI'. #0 0x9fffffffebe39f60:1 in ENTER_PTHREAD_LIBRARY_FUNC+0x61 () from /usr/lib/hpux64/libpthread.so.1 (gdb) packcore The core file has been added to '/tmp/ranga/itrc1/packcore.tar' Do you want to remove the original core file?(y or n) y The core file has been removed. (gdb) quit
--
ranga
[i work for hpe]
I was able to reproduce a somewhat similar crash with a much simpler case, not involving java/JVM.
#include <pthread.h>
int main ()
{
return pthread_num_processors_np();
}
[ crust 1 ] $ cat lib.c
void func() {}
[ crust 1 ] $ cc lib.c -b -o liblib.so -lpthread
[ crust 1 ] $ cc pnp.c -L. -llib -o pnp
[ crust 1 ] $ ./pnp
Segmentation fault (core dumped)
[ crust 1 ] $ pstack pnp core
core: pnp
-------------------------------- lwpid : 932124 -------------------------------
0: 60000000c0155961 : ENTER_PTHREAD_LIBRARY_FUNC() + 0x161 (/usr/lib/hpux32/libpthread.so.1)
1: 60000000c01a0d20 : pthread_num_processors_np() + 0xa0 (/usr/lib/hpux32/libpthread.so.1)
2: 00000000040008a0 : main() + 0x40 (pnp)
3: 60000000c008b920 : main_opd_entry() + 0x50 (/usr/lib/hpux32/dld.so)[ crust 1 ] $ ldd -v pnp
pnp:
find library=liblib.so; required by pnp
liblib.so => ./liblib.so
find library=libc.so.1; required by pnp
libc.so.1 => /usr/lib/hpux32/libc.so.1
find library=libpthread.so.1; required by ./liblib.so
libpthread.so.1 => /usr/lib/hpux32/libpthread.so.1
find library=libdl.so.1; required by /usr/lib/hpux32/libc.so.1
libdl.so.1 => /usr/lib/hpux32/libdl.so.1
[ crust 1 ] $ cc pnp.c -L. -llib -o pnp -lpthread
[ crust 1 ] $ ./pnp ; echo $?
8
[ crust 1 ] $ ldd -v pnp
pnp:
find library=liblib.so; required by pnp
liblib.so => ./liblib.so
find library=libpthread.so.1; required by pnp
libpthread.so.1 => /usr/lib/hpux32/libpthread.so.1
find library=libc.so.1; required by pnp
libc.so.1 => /usr/lib/hpux32/libc.so.1
find library=libdl.so.1; required by /usr/lib/hpux32/libc.so.1
libdl.so.1 => /usr/lib/hpux32/libdl.so.1At least this problem was because of library load order.
--
ranga
[i work for hpe]
@Jose M. del Rio wrote:Aha! This is getting more and more interesting!
The failiing program was indeed linked -lc before -lpthread:
cc +DD64 -o frmweb -L/weblogic12/Oracle_Home/lib/ -L/usr/lib/hpux64 -L/weblogic12/Oracle_Home/jdk//jre/lib/IA64W/ -L/weblogic12/Oracle_Home/jdk//jre/lib/IA64W/server/ -L/weblogic12/Oracle_Home/jdk//jre/lib/IA64W/native_threads/ \
/weblogic12/Oracle_Home/lib/s0nnmain.o \
/weblogic12/Oracle_Home/forms/lib/ssliftabw.o \
/weblogic12/Oracle_Home/forms/lib/ifzxtb.o \
/weblogic12/Oracle_Home/forms/lib/sixn.o \
/weblogic12/Oracle_Home/forms/lib/sixp.o \
\
-liplsn \
/weblogic12/Oracle_Home/forms/lib/istiif.o \
-u iiflmp -u iifget -u iiffcb -u iiflog -u iiflov -u iifgdl -u iifatr -u iifeue -u iifwcnew -u iifwru \
-libfrmw -liffw -lifcw -lijcw -liifw -lipc -lipfw -lipc -limffrmw -limc -liwfw -liwcw -litw -licw -lirm -lsosdw -lihm -libfrmw -lixw -liffw -lifcw -lijcw -lipfw -lipc -liicw -liiiw -liwfw -liwcw -liqw -litw -licw -lipc -lsosdw -limffrmw -limc -liplsn \
-lnn -lzrc -lvgsw -ldeb -lca -lmmoi -lmmcm -luicm -lrem -luiimg -ltio -luc -lutt -luicm -lrod -lror -lros -lrod -lror -lros -lrod -lutc -lutj -lutl -lutsl -lpls11 -lplp11 -lplc11 -lpls11 -lplp11 -lslax11 -lsql11 -dynamic /weblogic12/Oracle_Home/lib/nautab.o /weblogic12/Oracle_Home/lib/naeet.o /weblogic12/Oracle_Home/lib/naect.o /weblogic12/Oracle_Home/lib/naedhs.o -lm -lc -lclntsh `cat /weblogic12/Oracle_Home/lib/ldflags` -lnsgr11 -lnzjs11 -ln11 -lnl11 -lnro11 `cat /weblogic12/Oracle_Home/lib/ldflags` -lnsgr11 -lnzjs11 -ln11 -lnl11 -lnnz11 -lzt11 -lztkg11 -lclient11 -lnnetd11 -lvsn11 -lcommon11 -lgeneric11 -lmm -lsnls11 -lnls11 -lcore11 -lsnls11 -lnls11 -lcore11 -lsnls11 -lnls11 -lxml11 -lcore11 -lunls11 -lsnls11 -lnls11 -lcore11 -lnls11 `cat /weblogic12/Oracle_Home/lib/ldflags` -lnsgr11 -lnzjs11 -ln11 -lnl11 -lnro11 `cat /weblogic12/Oracle_Home/lib/ldflags` -lnsgr11 -lnzjs11 -ln11 -lnl11 -lclient11 -lnnetd11 -lvsn11 -lcommon11 -lgeneric11 -lsnls11 -lnls11 -lcore11 -lsnls11 -lnls11 -lcore11 -lsnls11 -lnls11 -lxml11 -lcore11 -lunls11 -lsnls11 -lnls11 -lcore11 -lnls11 -lclient11 -lnnetd11 -lvsn11 -lcommon11 -lgeneric11 -lsnls11 -lnls11 -lcore11 -lsnls11 -lnls11 -lcore11 -lsnls11 -lnls11 -lxml11 -lcore11 -lunls11 -lsnls11 -lnls11 -lcore11 -lnls11 `cat /weblogic12/Oracle_Home/lib/sysliblist` -lm `cat /weblogic12/Oracle_Home/lib/sysliblist` -ldl -lpthread -lm -lpthread -lc -lrt -lpthread -lc -lsnls11 -lpthread -lc
It should have been linked with the "-mt" option and without "-lpthread"; libc should never be linked explicitly.
Also:
ppoas1:/root#ldd -v /weblogic12/Oracle_Home/bin/frmweb
/weblogic12/Oracle_Home/bin/frmweb:
...
find library=libc.so.1; required by /weblogic12/Oracle_Home/bin/frmweb
libc.so.1 => /usr/lib/hpux64/libc.so.1...
find library=libpthread.so.1; required by /weblogic12/Oracle_Home/lib//libclntsh.so.11.1
libpthread.so.1 => /usr/lib/hpux64/libpthread.so.1So, as per the link you mentioned and your tests, it should ┬┐systematically? fail when calling pthread_num_processors_np?
Yes, I expect so.
--
ranga
[i work for hpe]
I relinked frmweb executable in the right order and it works!
Using "-mt" is recommended and supported, I suggest you do that instead.
--
ranga
[i work for hpe]