This Bugzilla instance is a read-only archive of historic NetBeans bug reports. To report a bug in NetBeans please follow the project's instructions for reporting issues.
dev build 200201090100 There seems to be a bug in Netbeans which triggers a total crash in IBM's JDK. FACTS: - I'm using a fresh user-dir. - I modified the default colors & fonts for Java files (attaching relevant XML files) - If I open a Java file directly, the JIT engine crashes - If I open a Text file first, then open the same Java file, the file opens just fine. - I don't think I ran into this problem until the 2nd or 3rd time Netbeans was restarted; maybe this is because the editor had already been opened when the color modification occured, thereby avoiding this bug. - Last week's build of Netbeans worked just fine. The key seems to be the XML files generated by Netbeans. If the first file I open uses custom colors & fonts, external XML files are used and the crash occurs. Otherwise files open just fine.. I would appreciate your help with this matter as it is quite severe. As I have reiterated in the past, reporting bugs to IBM is practically impossible and turn-around times between bug reports and fixes are at least 6 months, as such I would appreciate a workaround in Netbeans if possible. Thank you, Gili
Created attachment 4127 [details] \home\netbeans\system\Editors\text\x-java\fontsColors.xml
Created attachment 4128 [details] \home\netbeans\system\Editors\text\x-java\properties.xml
Created attachment 4129 [details] \home\netbeans\system\Editors\text\x-java\Settings.settings
I managed to track down the problem to Settings.settings. I deleted the file, entered Netbeans and opened a Java file without any problem. I then compared the newly-generated Settings.settings file against the old one and found them to be different. Copying the corrupt Settings.settings file back into place caused a crash again. I am attaching the "good" Settings.settings file now for you to compare against the corrupt one.. You will find that both XML files contain the _exact_ same keys, but in different order. It seems that loading objects in this particular order will cause a crash in IBM's JIT. My feeling is that this is probably a bug in Netbeans that should trigger an Exception by the compiler but instead sends it off crashing. I've done as much as I can on my end, the rest is up to you :) Please analyze the files and let me know if there is anything else you need me to run on my end to get this issue resolved. Also, I strongly suspect Issue #16257 is related; you be the judge.. Thank you..
Created attachment 4130 [details] "good" settings.settings file
Maybe editor's guys will try their luck. Settings.settings (what a nice name) belongs to their module. I can say following. I replaced my Settings.settings by your "good" and "bad" files. Under the "Editor Settings" node was missing just the "Java Editor" subnode. None exception was observed in both cases. It is strange. I do not think the order of instanceof elements in .settings file can cause the crash. I'm convinced that IBM JVM is the culprit but maybe I'm wrong. Definitely some thread dump after the crash and ide.log would be very usefull.
ide.log shows a normal exit (no error messages). As for a thread-dump, how does one get a thread-dump on an abnormal exit? I know how to get it in mid-executation but not on exit.. OS/2 gives me the following exit information: 01-11-2002 14:42:37 SYS3171 PID 01a4 TID 0006 Slot 00d5 D:\JAVA13\JRE\BIN\JAVAW.EXE c0000005 1d9fae8b P1=00000002 P2=01273714 P3=XXXXXXXX P4=XXXXXXXX EAX=00000000 EBX=00000000 ECX=01271000 EDX=00003000 ESI=00bc27e0 EDI=01271000 DS=0053 DSACC=f0f3 DSLIM=ffffffff ES=0053 ESACC=f0f3 ESLIM=ffffffff FS=150b FSACC=00f3 FSLIM=00000030 GS=0000 GSACC=**** GSLIM=******** CS:EIP=005b:1d9fae8b CSACC=f0df CSLIM=ffffffff SS:ESP=0053:01273718 SSACC=f0f3 SSLIM=ffffffff EBP=01273780 FLG=00012206 JITC.DLL 0001:0013ae8b but I doubt this will be of any help to you. SYS3175 (the exit condition mentioned above) maps to the following description: An access violation exception occurred and was generated when an attempt was made either to load or store data in an inaccessible location or to execute an inaccessible instruction. This exception corresponds to both the Intel 80386 processor general protection fault (#13), caused by an invalid access attempt, and the page fault (#14), caused by an attempt to access an uncommitted page or a page with incorrect attributes for the desired operation. This is definately a bug in IBM's JDK but like I said earlier, it might be getting triggered by Netbean's operations. At the very least I need to narrow down the problem to a reproducible testcase so I can forward it to IBM (they won't look at anything without a testcase) but even if I report it I don't want to wait 6 months for a fix from them.. Any ideas? :)
Hi, first of all to the settings files. As far as I know, editor has absolutely no control over how the settings file will look like - it has only control over the meaning of the file, and that is the same in both ("bad" and "good") cases. The problem with JVM bugs is that they are usualy reproducible only on the particular JVM. I think it is clear that this is JVM bug, because JVM can _NOT_ go down under any circumstaces. But, I think that - not depending whether the problem is only in JVM and NetBeans should or should not workaround it, or whether there is NetBeans bug and JVM bug together - the editor module can not do anything with it - it has no control over the syntax part of the settings file. Reassigning back to the core.
BTW, the Settings.settings files in editor settings are useless (at least what I know), so you can remove it without any loss of functionality.
I am going to close this issue as WONTFIX. We were unable to reproduce this issue here using sun jdk or ibm jdk on windows platform. Crash of the jvm is always bug in jvm. Sun jdk 1.4.0 prints stacktrace of involved thread before it crashes so it can be better traced what could involve the problem. No such info here. So we are unable to find root of this problem.
Gili, try out tomorrow dev build. I got rid of Settings.settings in editor settings MIME specific folder because only default layer file is valid. Although it is not the best solution, maybe it will solve the problem. Thanks, Mato
Hi Mato, Could you please explain the situation a little better? What do you mean "only default layer file is valid"? As well, I will try tomorrow's build and let you know if it fixes my problem. Lastly, I'd like to narrow this JDK bug down to a small testcase. Do you have any idea where I'd begin? The issue seems pretty extensive to me.. Thank you, Gili
Hi Gili, it will not solve the problem of loading *.settings files. It could be really JVM problem. I only eliminated creation of editor Settings.settings file in userDir/System.Editors/text/<MIMEFolder>/ and that could solve your problem. The file Settings.settings is typically created in default layer via editor xml layer file and you can find it in Default System/Editors/text/<MIMEFolder>/Settings.settings with no serialized data. Unfortunatelly, during setting of coloring map in editor options, some useless properties are serialized to Settings.settings and that's why Settings.settings file with serialized data is created under user dir. It is not possible to avoid the creation of this file, because of final method SharedClassObject.putProperty(...), that I cannot override. The creation is triggered by BaseOptions.firePropertyChange(...) I don't know how you could prepare your test case. Loading of *.settings is not done by editor module. Thanks, Mato
Martin, Your removal of "settings.settings" seemed to have worked.. I have used today's build of Netbeans for a few hours now with no noticable problems. Thanks :) Gili
Resolved for 3.4.x or earlier, no new info since then -> verified.
Resolved for 3.4.x or earlier, no new info since then -> closing.