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.
It is very frequent in the field to end up with a corrupted MDR cache. I recently visited one customer site, where a developer told me that NetBeans code completion didn't work. He showed me - System. produced "no suggestions". It turned out that his MDR cache was corrupted - I was able to fix the problem by deleting the cache. I frequently get into this state myself - it's difficult to say what is the triggering event. But it is much worse when a user gets into this state because - In a release build, the only indication that something is wrong is the flashing error icon - If the user did click it, they'd see a stack trace for an InvalidObjectException - they would have to search the web really well to discover that the fix was to delete $USERDIR/var/cache/mdrstorage - After that, code completion is simply broken, but it's not obvious that anything is wrong - A new user is likely to simply think NetBeans code completion doesn't actually work. This makes a very bad impression - possibly worse than visibly buggy software (some indication of failure) is software that looks like it never worked to begin with. MDR storage needs to be made self-repairing, regardless of whether we know all the root causes of this problem or not. It is too easy for a user to randomly get into this situation, and no clear way to recover from it whatsoever. I've made the (admittedly horrible) suggestion of a watchdog timer that, when the application is active, checks if the completions of "System." include "in", and deletes the MDR cache and initiates a rescan if that test fails. That's horribly ugly, and a really horrible way to do it - so better ideas would be great (maybe the constructor of an InvalidObjectException triggers an integrity check?). The one advantage of a watchdog system is that it is cheap to write and will solve the problem, and doesn't require large engineering investment in code we know will be defunct after 5.5. I don't think this can wait for 6.0. We are seeing it on customer visits, the problem happens to us when we're doing demos on stage, and users cannot recover from the situation. The IDE has enough information to know when the storage is corrupted, and rebuild it.
I cannot agree with Tims suggestion. InvalidObjectException is not detection, that MDR is corrupted. This exception might be thrown due to incorrect usage of Java Model APIs. BTW Some kind of rescanning is already implemented (File | Refresh All Files) I suppose, that Code Completion stops working, because some source is broken in terms of javac refuses to give correct data into MDR and the storage get's corrupted. But I beleive, that it's corrupted just for the broken file or broken file and all files related to this file. There are many problems with javac error recovery, which can be hardly fixed for NB 5.5. It is even possible (and I don't blame anyone - just trying not to overlook something), that the MDR is not corrupted, or better told it is not corrupted fatally - it is corrupted just for the broken file. And code completion fails to show results because e.g. it can iterate through some MDR collection and just one Element is broken, while the others are correct - but code completion still does not show anything. Just guessing. Things, that must be detected: 1. Can we reproduce this bug on tinny project? 2. If Code Completion stops working, currently edited file is broken -> What happens, when all compilation errors are fixed? -> will the code completion start to work again? 3. When the code completion doesn't work -> does it mean that it doesn't work just for one file? Or for all files within given project? Or within whole IDE? 4. Does File | Refresh All Files fix the problem? BTW I added dependencies to all InvalidObjectException reports.
BTW see 65815. It also can cause, that code completion does not work. The fix of 65815 is in trunk, but not in 5.5
Reproducible testcase for IOE from MDR: 1) start with fresh userdir 2) open NB sources (tested with Java module) 3) open some class 4) add inner class: class Inner { } 5) wait for the sources to be parsed 6) delete inner class 7) place caret to different position 8) write class In and invoke CC 9) write rest of the word Inner -> IOE the steps 6) - 8) should be performed quicky to avoid parsing the sources. If the exception does not occurre try opening more NB modules. Tested with NB 5.0 fcs , 6.0 200627030859 Linux, WinXP JDK 1.6.0b77, 1.5.0_06
Created attachment 29442 [details] IOE
Is the MDR storage corrupted after IOE? Does Code Completion stop working after IOE?
The CC is working, this is only a way how to get an exception from MDR. I've posted it here since this is umbrella for InvalidObjectException reports.
Next time please create separate issue and attach _whole_ message.log not just exception. message.log can contain valuable information to track down this type of bug. Thanks.
The issue jiriprox described is similar to issue 70437. It is not critical. Dan will look at it.
InvalidObjectException mentioned above fixed in trunk. A check for jmi object validity was missing in the related source code. This exception is not somehow extraordinary and should not break mdr storage consistency. /cvs/java/editor/src/org/netbeans/modules/editor/java/JMIUtils.java new revision: 1.48; previous revision: 1.47
*** Issue 73157 has been marked as a duplicate of this issue. ***
I guess, that issue 75032 is the root cause. Just guessing.
*** Issue 74271 has been marked as a duplicate of this issue. ***
Checking in FileScanner.java; /cvs/java/javacore/src/org/netbeans/modules/javacore/scanning/FileScanner.java,v <-- FileScanner.java new revision: 1.27; previous revision: 1.26 done The problem was in different timezones: when preparsed storage was created in different timezone, it's timestamp was not >= than timestamp of jar. Thanks to thurka and psuchomel for identifying the problem.
Verified in 200606081800, can be merged to 5.5 branch.
Checking in FileScanner.java; /cvs/java/javacore/src/org/netbeans/modules/javacore/scanning/FileScanner.java,v <-- FileScanner.java new revision: 1.26.28.1; previous revision: 1.26 done
Verified. NB 5.5 200606160200
I just tested this on the 20060619 build and I can still corrupt the MDR storage following these steps (sorry, they're complicated, but reproducable): 1) Download and install JBoss 4.0.4 GA and add the JBoss Server to NetBeans. 2) Create 2 class libraries using the attached jar files: - JBossSeam - jboss-seam.jar - JBossSeamUI - jboss-seam-ui.jar 3) Unzip the attached RegistrationInterceptorAnnotation.zip and open the project. Allow the classpath scanning to finish. Close the project and close NetBeans. 4) Delete the project folder (regisration). 5) Unzip the attached RegistrationReset.zip 6) Start NetBeans and open the Registration project again. 7) Open User.java and try to add an annotation @Name at the top of the class file. You'll get the InvalidObjectException and code completion will no longer work.
Created attachment 31318 [details] JBoss Seam JAR
Created attachment 31319 [details] JBoss Seam UI JAR
Created attachment 31320 [details] RegistrationInterceptorAnnotation Project
Created attachment 31321 [details] RegistrationReset Project
Opened as issue 78916 instead.
*** Issue 68998 has been marked as a duplicate of this issue. ***
*** Issue 78861 has been marked as a duplicate of this issue. ***
*** Issue 82411 has been marked as a duplicate of this issue. ***
Reorganization of java component