Actually I found to run multiple instances of testing (such as to run
"build.sh reg.test" and "build.sh kernel.test" at the same time), more
intermittent failures will happen. Mostly in my experiments, the
failures throw something with threading-related tests, for example,
the kernel test java.lang.ThreadTest fails more frequently. But it's
hard to debug since the failure is very indefinite, hard to reproduce.
It's great you cooked up such a small test case.
Thanks,
xiaofeng
On 4/26/07, Chris Elford (JIRA) <[EMAIL PROTECTED]> wrote:
Failure running multiple instances of debug version of Harmony
--------------------------------------------------------------
Key: HARMONY-3756
URL: https://issues.apache.org/jira/browse/HARMONY-3756
Project: Harmony
Issue Type: Bug
Components: DRLVM
Environment: Windows XP -- MSVC DEBUG build of harmony-hdk-r532358
Reporter: Chris Elford
Priority: Minor
Has anyone else seen issues running multiple instances debug builds of Harmony
at the same time?
public class Sleep {
public static void main(String[] arg) {
System.out.println("About to sleep for 60 secs");
try {
Thread.sleep(60*1000);
} catch (Exception e) {
}
System.out.println("Slept for 60 secs");
}
}
From two different windows CMD windows run
"C:\java\harmony-hdk-r532358\jdk\jre\bin\java.exe Sleep"
The first one starts correctly but the second one gets an access violation in
memset during startup.
Executable search path is:
ModLoad: 00400000 0040e000 C:\java\harmony-hdk-r532358\jdk\jre\bin\java.exe
ModLoad: 7c900000 7c9b0000 C:\WINNT\system32\ntdll.dll
ModLoad: 7c800000 7c8f4000 C:\WINNT\system32\kernel32.dll
ModLoad: 11100000 1111d000 C:\java\harmony-hdk-r532358\jdk\jre\bin\HYPRT.dll
ModLoad: 10000000 10425000 C:\java\harmony-hdk-r532358\jdk\jre\bin\HYTHR.dll
ModLoad: 71ab0000 71ac7000 C:\WINNT\system32\WS2_32.dll
ModLoad: 77c10000 77c68000 C:\WINNT\system32\msvcrt.dll
ModLoad: 71aa0000 71aa8000 C:\WINNT\system32\WS2HELP.dll
ModLoad: 77dd0000 77e6b000 C:\WINNT\system32\ADVAPI32.dll
ModLoad: 77e70000 77f01000 C:\WINNT\system32\RPCRT4.dll
ModLoad: 7c340000 7c396000 C:\java\harmony-hdk-r532358\jdk\jre\bin\MSVCR71.dll
ModLoad: 00510000 00ad5000
C:\java\harmony-hdk-r532358\jdk\jre\bin\default\harmonyvm.dll
ModLoad: 00370000 00383000
C:\java\harmony-hdk-r532358\jdk\jre\bin\default\zlib1.dll
ModLoad: 4a800000 4a8c8000 C:\java\harmony-hdk-r532358\jdk\jre\bin\icuuc34.dll
ModLoad: 4ad00000 4b570000 C:\java\harmony-hdk-r532358\jdk\jre\bin\icudt34.dll
ModLoad: 59a60000 59b01000 C:\WINNT\system32\dbghelp.dll
ModLoad: 77c00000 77c08000 C:\WINNT\system32\VERSION.dll
ModLoad: 74320000 7435d000 C:\WINNT\system32\ODBC32.dll
ModLoad: 5d090000 5d12a000 C:\WINNT\system32\COMCTL32.dll
ModLoad: 77f10000 77f57000 C:\WINNT\system32\GDI32.dll
ModLoad: 7e410000 7e4a1000 C:\WINNT\system32\USER32.dll
ModLoad: 7c9c0000 7d1d5000 C:\WINNT\system32\SHELL32.dll
ModLoad: 77f60000 77fd6000 C:\WINNT\system32\SHLWAPI.dll
ModLoad: 763b0000 763f9000 C:\WINNT\system32\comdlg32.dll
ModLoad: 76bf0000 76bfb000 C:\WINNT\system32\PSAPI.DLL
ModLoad: 769c0000 76a73000 C:\WINNT\system32\USERENV.dll
ModLoad: 71a50000 71a8f000 C:\WINNT\system32\MSWSOCK.dll
ModLoad: 76390000 763ad000 C:\WINNT\system32\IMM32.DLL
ModLoad: 629c0000 629c9000 C:\WINNT\system32\LPK.DLL
ModLoad: 74d90000 74dfb000 C:\WINNT\system32\USP10.dll
ModLoad: 773d0000 774d3000
C:\WINNT\WinSxS\x86_Microsoft.Windows.Common-Controls_6595b64144ccf1df_6.0.2600.2982_x-ww_ac3f9c03\comctl32.dll
ModLoad: 20000000 20017000 C:\WINNT\system32\odbcint.dll
ModLoad: 77fe0000 77ff1000 C:\WINNT\system32\Secur32.dll
ModLoad: 01300000 0136d000
C:\java\harmony-hdk-r532358\jdk\jre\bin\default\em.dll
ModLoad: 01380000 01967000
C:\java\harmony-hdk-r532358\jdk\jre\bin\default\jitrino.dll
ModLoad: 01980000 019b0000
C:\java\harmony-hdk-r532358\jdk\jre\bin\default\gc_gen.dll
ModLoad: 019b0000 01a37000 C:\WINNT\system32\MSVCR71D.dll
(11ac.1468): Access violation - code c0000005 (!!! second chance !!!)
eax=00000000 ebx=7ffdc000 ecx=0347c000 edx=00000000 esi=0013f884 edi=22e30000
eip=019c6085 esp=0013f7d0 ebp=0013f7ec iopl=0 nv up ei pl nz na pe nc
cs=001b ss=0023 ds=0023 es=0023 fs=003b gs=0000 efl=00000206
MSVCR71D!memset+0x45:
019c6085 f3ab rep stos dword ptr es:[edi] es:0023:22e30000=????????
0:000> k
ChildEBP RetAddr
0013f7d0 01986de2 MSVCR71D!memset+0x45
[F:\VS70Builds\3077\vc\crtbld\crt\src\intel\memset.asm @ 108]
0013f7ec 0198c2b8 gc_gen!fspace_initialize+0xb2
[c:\lab_drlbuild\combined_msvc_d\s0426\working_vm\vm\gc_gen\src\trace_forward\fspace.cpp
@ 50]
0013f804 0198b8be gc_gen!gc_nos_initialize+0x18
[c:\lab_drlbuild\combined_msvc_d\s0426\working_vm\vm\gc_gen\src\gen\gen.h @ 125]
0013f864 0198a061 gc_gen!gc_gen_initialize+0x37e
[c:\lab_drlbuild\combined_msvc_d\s0426\working_vm\vm\gc_gen\src\gen\gen.cpp @
196]
*** WARNING: Unable to verify checksum for
C:\java\harmony-hdk-r532358\jdk\jre\bin\default\harmonyvm.dll
0013f87c 0063cc4d gc_gen!gc_init+0x91
[c:\lab_drlbuild\combined_msvc_d\s0426\working_vm\vm\gc_gen\src\common\gc_for_vm.cpp
@ 51]
0013f9d8 005a2fdf harmonyvm!vm_init1+0x30d
[c:\lab_drlbuild\combined_msvc_d\s0426\working_vm\vm\vmcore\src\init\vm_init.cpp
@ 679]
*** WARNING: Unable to verify checksum for
C:\java\harmony-hdk-r532358\jdk\jre\bin\java.exe
0013fa60 004021f0 harmonyvm!JNI_CreateJavaVM+0x1cf
[c:\lab_drlbuild\combined_msvc_d\s0426\working_vm\vm\vmcore\src\jni\jni.cpp @
499]
0013faac 00401a91 java!invocation+0xb0
[c:\lab_drlbuild\combined_msvc_d\s0426\working_classlib\modules\luni\src\main\native\launcher\shared\main.c
@ 670]
0013fb78 004010c5 java!gpProtectedMain+0x771
[c:\lab_drlbuild\combined_msvc_d\s0426\working_classlib\modules\luni\src\main\native\launcher\shared\main.c
@ 393]
0013ff60 0040469d java!main+0xb5
[c:\lab_drlbuild\combined_msvc_d\s0426\working_classlib\modules\luni\src\main\native\launcher\shared\cmain.c
@ 147]
On a possibly related note, the crash happens right where a "redundant" load of
gc_gen and MSVCR71D happens in a single VM case. I'm not sure why the same libraries are
loaded multiple times... windbg log:
...
ModLoad: 01300000 0136d000
C:\java\harmony-hdk-r532358\jdk\jre\bin\default\em.dll
ModLoad: 01380000 01967000
C:\java\harmony-hdk-r532358\jdk\jre\bin\default\jitrino.dll
ModLoad: 01980000 019b0000
C:\java\harmony-hdk-r532358\jdk\jre\bin\default\gc_gen.dll
ModLoad: 019b0000 01a37000 C:\WINNT\system32\MSVCR71D.dll
ModLoad: 01980000 019b0000
C:\java\harmony-hdk-r532358\jdk\jre\bin\default\gc_gen.dll
ModLoad: 019b0000 01a37000 C:\WINNT\system32\MSVCR71D.dll
ModLoad: 13100000 13106000 C:\java\harmony-hdk-r532358\jdk\jre\bin\hysig.dll
ModLoad: 11700000 11718000 C:\java\harmony-hdk-r532358\jdk\jre\bin\hyzlib.dll
...
The workaround for this issue is to not run multiple debug instances of java at
the same time and to instead use release builds. That is unfortunate in my
case because the workload I really want to run features a java process that
spawns another java process.
On a probably unrelated note, it still looks like the debug builds are loading
three different sets of C runtime libraries. MSVCRT, MSVCR71 and MSVCR71D (see
HARMONY-2827 for a similar problem on linux)
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
--
http://xiao-feng.blogspot.com
