IV34398: JVM CRASH WHILE INVOKING SDK/BIN/JAVA FROM JRE/BIN OF ANOTHER JD K
Closed as program error.
Error Message: N/A . Stack Trace: Unhandled exception Type=Segmentation error vmState=0x00040000 J9Generic_Signal_Number=00000004 ExceptionCode=c0000005 ExceptionAddress=77A432A0 ContextFlags=0001007f Handler1=7272F590 Handler2=742BEE70 InaccessibleAddress=00DADE32 EDI=00380000 ESI=00DADE30 EAX=00100000 EBX=00DC2820 ECX=00000000 EDX=000007FF EIP=77A432A0 ESP=003CE440 EBP=003CE468 EFLAGS=00010246 GS=002B FS=0053 ES=002B DS=002B Module=C:\Windows\SysWOW64\ntdll.dll Module_base_address=77A10000 Offset_in_DLL=000332a0 Target=2_60_20120618_113791 (Windows 7 6.1 build 7601 Service Pack 1) CPU=x86 (4 logical CPUs) (0x1f8b3c000 RAM) ----------- Stack Backtrace ----------- RtlImageNtHeader+0x11c (0x77A432A0 <OSB>ntdll+0x332a0<CSB>) RtlImageNtHeader+0x423 (0x77A435A7 <OSB>ntdll+0x335a7<CSB>) RtlImageNtHeader+0x30e (0x77A43492 <OSB>ntdll+0x33492<CSB>) HeapFree+0x14 (0x759314DD <OSB>kernel32+0x114dd<CSB>) free+0x1c (0x7263016A <OSB>MSVCR100+0x1016a<CSB>) __dllonexit+0x2b8 (0x73DF174A <OSB>dbgwrapper+0x174a<CSB>) VMprJavaSendNative+0x4a0 (jnisend.asm:481, 0x727444F0 <OSB>j9vm26+0x244f0<CSB>) java_lang_J9VMInternals_initializeImpl+0xad (internals.asm:1048, 0x71876E4D <OSB>jclscar_26+0x6e4d<CSB>) resolveStaticMethodRefInto+0x121 (resolvesupport.c:294, 0x727656B1 <OSB>j9vm26+0x456b1<CSB>) resolveStaticMethodRef+0x21 (resolvesupport.c:323, 0x72765741 <OSB>j9vm26+0x45741<CSB>) resolveHelper+0x57f (javamisc.asm:1187, 0x72736C5F <OSB>j9vm26+0x16c5f<CSB>) standardInit+0x1ff (stdinit.c:198, 0x718ABC5F <OSB>jclscar_26+0x3bc5f<CSB>) scarInit+0x18c (vm_scar.c:325, 0x718B072C <OSB>jclscar_26+0x4072c<CSB>) J9VMDllMain+0x122 (vm_scar.c:390, 0x718B10E2 <OSB>jclscar_26+0x410e2<CSB>) runJ9VMDllMain+0x10e (jvminit.c:2311, 0x727551CE <OSB>j9vm26+0x351ce<CSB>) pool_do+0x56 (pool.c:637, 0x7277F3A6 <OSB>j9vm26+0x5f3a6<CSB>) runInitializationStage+0x57 (jvminit.c:2262, 0x727588F7 <OSB>j9vm26+0x388f7<CSB>) protectedInitializeJavaVM+0x534 (jvminit.c:5106, 0x72759C04 <OSB>j9vm26+0x39c04<CSB>) j9sig_protect+0x44 (j9signal.c:150, 0x742BF054 <OSB>J9PRT26+0xf054<CSB>) initializeJavaVM+0x184 (jvminit.c:953, 0x72759DC4 <OSB>j9vm26+0x39dc4<CSB>) JNI_CreateJavaVM+0x65 (jniinv.c:101, 0x72743555 <OSB>j9vm26+0x23555<CSB>) JNI_CreateJavaVM+0x166d (jvm.c:2097, 0x742E823D <OSB>jvm+0x823d<CSB>) JNI_CreateJavaVM+0x29a (redirector.c:882, 0x7440559A <OSB>jvm+0x559a<CSB>) handleClose+0x1 (io_util_md.c:528, 0x00402E32 <OSB>java+0x2e32<CSB>) canonicalize+0x2bc (canonicalize_md.c:287, 0x004098DE <OSB>java+0x98de<CSB>) (0x7865206C) (0x64657272) (0x5020202E) ?_IsCanceling@_TaskCollection@details@Concurrency@@QAE_NXZ+0xfe9 (0x72676F72 <OSB>MSVCR100+0x56f72<CSB>) (0x77206D61) (0x206C6C69) (0x74697865) --------------------------------------- JVMDUMP039I Processing dump event "gpf", detail "" at 2013/01/09 07:47:16 - please wait. . The crash occurred only when the current working directory is the sdk/jre/bin of one JDK and invoking the java executable in the sdk/bin of different JDK. The problem did not happen if the current directory is not not sdk/jre/bin or if the java executable from sdk/jre/bin of another JDK.
Use one of the following option to work around the issue: Option 1: Change the current working directory from sdk/jre/bin to some other directory. Option 2: Always invoke the java executable in sdk/jre/bin. Avoid invoking the java executable of sdk/bin when the current working directory is sdk/jre/bin of another JDK. Option 3: Copy dbgwrapper.dll from sdk/jre/bin to sdk/bin in the target JVM.
The reported crash problem occurred when the dependent dll (dbgwrapper.dll) is loaded by the system. The search sequence is: first the invoking executable path, then the current working directory followed by other paths including the Java Library Path. In case of an installer application for which the current working directory is set as Java 7 sdk/jre/bin and it can invoke any target JVM for different products to be installed. When it installs a product with a different JDK than the installer and if it invokes the java executable in sdk/bin, as sdk/bin does not have dbgwrapper.dll, the dll is loaded from the current working directory which is Java 7 sdk/jre/bin. This results in a crash as Java 7 dbgwrapper.dll is not compatible with the target JDK dlls.
This defect will be fixed in: 7.0.0 SR5 . The JDK has been updated to rename the dbgwrapper.dll in the jre/bin to dbgwrapper70.dll which would be pre-loaded by the JVM during the initialization. With this fix, the dbgwrapper.dll would not be found in the current working directory (Java 7 sdk/jre/bin) and would be loaded from target Java library path
Reported component name
JAVA CLASS LIBS
Reported component ID
Last modified date
APAR is sysrouted FROM one or more of the following:
APAR is sysrouted TO one or more of the following:
Fixed component name
JAVA CLASS LIBS
Fixed component ID
Applicable component levels