Bug ID: JDK-6532325 VM crashes after setting file associations in Eclipse 3.2

Type: Bug
Component: hotspot
Sub-Component: compiler
Affected Version: 6

Priority: P3
Status: Closed
Resolution: Not an Issue
OS: windows_xp
CPU: x86

Submitted: 2007-03-08
Updated: 2011-02-16
Resolved: 2007-08-06

FULL PRODUCT VERSION :
java version "1.6.0"
Java(TM) SE Runtime Environment (build 1.6.0-b105)
Java HotSpot(TM) Client VM (build 1.6.0-b105, mixed mode, sharing)

ADDITIONAL OS VERSION INFORMATION :
Microsoft Windows XP [Version 5.1.2600]

EXTRA RELEVANT SYSTEM CONFIGURATION :
SP2
all updates form microsoft.com installed

A DESCRIPTION OF THE PROBLEM :
Eclipse 3.2 crashes after changing File associations

Indices:
- this crash happens only on my machine. we have tested it on serveral others

Remark:
I have had this bug with JRE 1.5. On testing with JRE 1.6 RC1 -> the bug did not occur any more now with JRE 1.6 the bug occurrs again

STEPS TO FOLLOW TO REPRODUCE THE PROBLEM :
The bug occurrs when using Eclipse 3.2.2: buildId=M20070212-1330

Steps to reproduce the crash:
- newly installed eclipse, no workspace
- Start eclipse
- Open Window -> Preferences -> General -> Editors -> File Associations
- Select *.html
- Remove associated editor "Web Browser"
- Add internal Editor: Text Editor
- Ok
- File -> New -> Project -> Java Project -> next
 -> VM crashes: see attachment with log-file


ERROR MESSAGES/STACK TRACES THAT OCCUR :
Attached seperatly


REPRODUCIBILITY :
This bug can be reproduced always.

EVALUATION A fastdebug JVM crashes in the following way: 0012e6a0 7c91e89a ntdll!KiFastSystemCallRet 0012e6a4 7c81cd96 ntdll!ZwTerminateProcess+0xc 0012e7a0 7c81cdee kernel32!_ExitProcess+0x62 0012e7b4 08325a53 kernel32!ExitProcess+0x14 0012e7c8 083259fc jvm!__crtExitProcess+0x43 [f:\vs70builds\3077\vc\crtbld\crt\src\crt0dat.c @ 464] 0012e7f8 08325890 jvm!doexit+0x11c [f:\vs70builds\3077\vc\crtbld\crt\src\crt0dat.c @ 414] 0012e80c 0827052c jvm!exit+0x10 [f:\vs70builds\3077\vc\crtbld\crt\src\crt0dat.c @ 303] 0012e814 0830d82d jvm!os::abort+0x1c [c:\prtbuilddir\workspace\src\os\win32\vm\os_win32.cpp @ 812] 0012e860 080effb3 jvm!VMError::report_and_die+0x67d [c:\prtbuilddir\workspace\src\share\vm\utilities\vmerror.cpp @ 794] 0012e89c 0826eaa9 jvm!report_assertion_failure+0x43 [c:\prtbuilddir\workspace\src\share\vm\utilities\debug.cpp @ 192] 0012e8e4 0826ec15 jvm!verify_block+0x99 [c:\prtbuilddir\workspace\src\share\vm\runtime\os.cpp @ 382] 0012e8f0 0816d437 jvm!os::free+0x45 [c:\prtbuilddir\workspace\src\share\vm\runtime\os.cpp @ 466] 0012e910 08190b54 jvm!jni_ReleaseCharArrayElements+0x237 [c:\prtbuilddir\workspace\src\share\vm\prims\jni.cpp @ 2217] 0012e934 010ebbd3 jvm!checked_jni_ReleaseCharArrayElements+0x1c4 [c:\prtbuilddir\workspace\src\share\vm\prims\jnicheck.cpp @ 1452] WARNING: Stack unwind information not available. Following frames may be wrong. 0012e990 082ee407 swt_win32_3346!Java_org_eclipse_swt_internal_win32_OS_RegQueryValueExW__I_3CI_3I_3C_3I+0xc9 This suggests that size reported in the lpcbData argument to RegQueryValueExW is bigger than the actual size of lpData so it's overwriting data in the C heap. This looks like an SWT problem.

06-08-2007

EVALUATION Looking at the hs_err log file excerpt in the Comments section, it says it's crashed in the compiler thread. This should be a compiler bug. It's the Client compiler. Current thread (0x16b47c00): JavaThread "CompilerThread0" daemon [_thread_in_native, id=5448] Current CompileTask: C1: 11% com.ibm.icu.text.RBBIDataWrapper.get(Ljava/io/InputStream;)Lcom/ibm/icu/text/RBBIDataWrapper; @ 460 (973 bytes) The stack trace is useless though.

21-05-2007

EVALUATION Looking at the two crash reports on the eclipse bug pages we seem to be dealing with two completely different crashes. The older 1.5 crash is in the VMThread, during part of GC by the looks of it. The newer crash is in ntdll and it would appear to be a library issue - problem some msvc71 vs. msvc6 conflict.

08-03-2007