If we try to create Java VM after initializing the DB2 and making calls to
access table, the Hotspot VM results in the following error and program hangs:


Call JNI_CreateJavaVM
#
# HotSpot Virtual Machine Error, Internal Error
#
[error occured during error reporting]

Similar problem is found while using this program with Oracle OCI calls.

*** It results in same error using Java 1.3 (Hotspot).

N/A

  xxxxx@xxxxx   2000-08-21

This is the output when the test I got from Kesari was run with a b27 debug
VM.  See the attachment for the test.  The test had to be run on a machine with
a db2 installation.

$ ./test
beginning execution...

** Return code from db connect func = -1
Call JNI_CreateJavaVM
#
# HotSpot Virtual Machine Error, Internal Error
# Please report this error at
# http://java.sun.com/cgi-bin/bugreport.cgi
#
# Fatal: Encountered unexpected pre-existing sigaction handler 0xfe3e14b4 for signal 10.
#
[error occured during error reporting]
Segmentation Fault(coredump)



I added this line to the test.

40a41
>    vmOptions[ixVMoptions++].optionString = (char *) "-XX:+AllowUserSignalHandlers";

and got this

$ ./test
beginning execution...

** Return code from db connect func = -1
Call JNI_CreateJavaVM
VM option '+AllowUserSignalHandlers'
Created the Java VM rcode = 0
$ 




  xxxxx@xxxxx   2000-08-21

By using this flag the problem appears to be solved. As per the discussion I had
with Joe, this flag is internal and can not be suggested for ISV
to go ahead with the modification. As this is not a workable solution,
we need to keep this bug open till we get a suitable work around for Peoplesoft.
I will not be suggesting this workaround to Peoplesoft until the issue of 
support for this flag is clarified.
Here the problem is with the signal handlers and most of the databases like Oracle, DB2 will define their own signal handlers and also the ISV application
uses SIGUSR1. This problem occurs if JVM finds that user (in this case the 
database) has already defined the handlers for SIGSEGV, SIGBUS.

---

Please also see RFE 4381843 for more info.

  xxxxx@xxxxx   2001-07-31

Please note: In have an open defect 4366535 which may be related

That JNI_CreateJavaVM seg faults without giving any error 
message in this situation is ridiculous. (It just cost me 
more than a day of work and I expect I'm not the only one.)

What are the side effects of -XX:+AllowUserSignalHandlers? 
I'd guess this affects optimizations in HotSpot that are 
depending on getting control for segmentation violations on 
NULL pointer dereferences or stepping over the end of a 
allocation pool region. If this is the case, does the 
AllowUserSignalHandlers turn off the optimizations, or does 
it just leave things in a bad state? If it disables the 
optimizations, I'd suggest making this the default and 
requiring a flag to turn on the optimizations. User 
installed singal handlers are hardly uncommon in reall 
applications. (E.g. catch SIGSEGV to checkpoint files or 
write an error log entry, etc.)

As well as agreeing with the ridiculousness of the error 
message on this bug I wanted to mention that the same thing 
happens with mixing IBM's MQSeries and creating a JVM. The -
XX option is helping for now but I want to see a permanent 
resolution to this.

I echo ralphc that this bug exists when using IBM MQSeries
libraries and creating a JVM.  I have worked full time on
this problem for 2 weeks and I would have never come across
this bug report if someone else hadn't pointed it out to
me.  The information given from the hotspot error is useless
and even the stack trace, etc. from debugging didn't point
me to thinking it was a signal handler problem.  I have
spent 2 weeks tracking what I thought was a threading
problem.   Just happy to find the workaround!  I am
concerned about the stability and production wrthiness of
this option string however.  I would like to see a suitable
long term fix other than this undocumented option.