Java core dumps signal 11

[Iain Bell]

The third party Java software we are trying to run on HP-UX. Java version 1.2.2.13 and unfortunatley people who provided code do not support 1.3... The code attaches to an ORacle database the following is the end of the log file.

Any comments welcome


Stack_Trace: error while unwinding stack
( 0) 0xc2b0274c report_error__FPciN21e + 0x54 [/opt/java1.2/bin/../jre/lib/P
A_RISC2.0/hotspot/libjvm.sl]
( 1) 0xc2be6e50 JVM_handle_hpux_signal + 0x390 [/opt/java1.2/bin/../jre/lib/
PA_RISC2.0/hotspot/libjvm.sl]
( 2) 0xc2be6aac signalHandler__FiP9__siginfoPv + 0x14 [/opt/java1.2/bin/../j
re/lib/PA_RISC2.0/hotspot/libjvm.sl]
( 3) 0xc01f2ee8 _sigreturn [/usr/lib/libc.2]
#
# Java version:
# HotSpot VM (1.0.1fcs, mixed mode, PA2.0 build 1.2.2.13-02/04/21-PA_RISC2.0)
# HotSpot Virtual Machine Error, Unexpected Signal 11
#
# occurred at pc=0
# Error happened during: scavenge
#
# Error ID: /CLO/Components/JAVA_HOTSPOT/Src/build/hp-ux/../../src/os/hp-ux/vm/o
s_hp-ux.cpp, 3075

[Alex Glennie]

Could you name the 3rd party application ?

I can check if we have any known issues wrt to it within HP ? If you have a support contract with HP it would be worth your while getting the core file into to your local Response Centre ..... ?

[Iain Bell]

The application is called Markview written by 170systems and is used for viewing scanned documents.

I will investigate sending the core dump

[Jeff Schussele]

Hi Iain,

Signal 11 is a SIGSEGV or segmentation fault, which frequently means you've overrun a memory segment value somewhere.
Quite often it turns out to be maxssiz, maxdsiz or maxtsiz kernel parameters. Roughly meaning that a process has grown it's stack, data or text size larger than allowed.
Can also mean that you've exhausted shared memory for a 32-bit application.
Sometimes these can be traced back to a application that's leaking memory badly - particularly a 32-bit app.
But you've definitely run into a type of memory limitation with this error.

Rgds,
Jeff

[Leslie Chaim]

I once had the a similar problem, except that it written by me:)

After reviewing the code, again and again I blissfully blamed the JVM;) and to my shock I was right!

I upgraded to the JDK 1.4 and all is fine.

[Iain Bell]

Jeff

Thanks for your comment I spent a lot of usefull time playing with these parameters and believe I learnt alot of new configuration options that could be useful in the future.

In the end it turned out the DBA had turned on a timeout feature (in sqlnet.ora expire_timeout) and this seemed to be the cause. After removing this parameter things have settled down - it was unfortunate that this change and the switch to unix based OC4J happened at the same time.

Thanks for the replies
Iain