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.
Summary: | AssertionError during startup | ||
---|---|---|---|
Product: | projects | Reporter: | jadjong <jadjong> |
Component: | Libraries | Assignee: | Tomas Zezula <tzezula> |
Status: | RESOLVED FIXED | ||
Severity: | blocker | CC: | dkonecny, jadjong, jglick, jtulach, mkubec, rmatous, ttran |
Priority: | P2 | ||
Version: | 4.x | ||
Hardware: | PC | ||
OS: | Linux | ||
Issue Type: | DEFECT | Exception Reporter: | |
Bug Depends on: | |||
Bug Blocks: | 41535 |
Description
jadjong
2004-09-22 12:52:11 UTC
please attach your $HOME/.netbeans/4.0beta1/var/log/messages.log Same as issue #49037. No idea how to reproduce in that case. Reporter, please mention anything vaguely unusual about your home directory or NB $userdir - use of network drives, symlinks, etc. Priority decreased to P3 because there isn't way how to reproduce. Is it permanent problem, random or it occured just once ? Are there any special steps how to reproduce ? Anyway please provide as much information as you can. The problem is persistent and occurs at each startup of Netbeans. Uninstalling Netbeans, deleting the $HOME/.netbeans directory and re-installing Netbeans did not help. Since you cannot reproduce this error it may have to do with my specific Linux configuration. Therefore, I plan to download the source code to try to debug this issue myself. Great, I really apreciate it. Maybe you could run unit tests for masterfs. There would be interesting to see if some test fail. There is necessary : 1/ checkout sources 2/ build IDE 3/ build xtest (in folder xtest launch ant build.xml) 4/ run tests for masterfs (in folder openide\masterfs\test launch ant build.xml) 5/ results can be found in openide\masterfs\test\results\index.html Also try a different user directory. Just try with e.g. ..../netbeans --userdir /tmp/test49405 (a not-yet-existent dir) and see if you still have the same problem. If so, then I have no clue what could be wrong. If not, then something about your home dir is breaking masterfs. I just tried your suggestion last night: ..../netbeans --userdir /tmp/test49405 The same AssertionError came back. Also reinstalling with an older VM (1.4.2 in stead of 1.5.0-rc1) did not help. So, there is apparently some special strange configuration on my machine. I'll look more into this during the coming week. I get this too on startup. Dev build 200409281800. I just installed the Subversion profile into Netbeans. Not sure if that has anything to do with it. Other than that, everything runs like normal. Observed and reported to me by word of mouth many times. Reassigned to Jarda because this issue seems to be caused by AbstractLookup.ISE. I would say that URLMapper doesn't get proper set of providers (espicially the one provided by MasterFileSystem). Jarda, please look at it. Milan, your test failures may be related to this. If it's really the issue I'm facing then I'm able to reproduce it when running projects/projectui tests. In that test call of FileUtil.toFileObject(getWorkDir()) returns null, despite getWorkDir() returns existing File object. Re. Milan's last comment - he reports that masterfs.jar was accidentally left off the classpath in his case, so that is the explanation. Jesse, thanks for explanation, I was about to write it here. Is it really necessary to do all the work in constructor of LibraryStorage? The lookup is a bit fragile for bunch of operations from its constructor, as it is not reentrant. The lookup tries to recover from reentrant access, but we have recently had few failures in filesystems as the interaction between lookup and filesystems needs to be very close and happens very early in the startup sequence. So if I can ask, please fix the LibraryStorge constructor. Has to be run during startup, though not necessarily in that particular constructor. I can move it from the constructor, but it has to be done during start up (ModuleInstall.restore ()). Jardo, will it help? yes, it will help. The reentrancy problem in lookup is caused by calling lookup once more from the lookup. What is likely happening in this case is that lookup calls constructor of LibrariesStorage and it calls PropertiesUtils and they call URLMapper and it calls lookup and the lookup is not able to answer the question. If the LibrariesStrorage constructor was more lightweight, then the lookup called the constructor and that is all. Later someone would call a method on LibrariesStorages and then the rest of the initialization should be ok. Ok. Checking in libraries/src/org/netbeans/modules/project/libraries/LibrariesModule.java; /cvs/projects/libraries/src/org/netbeans/modules/project/libraries/LibrariesModule.java,v <-- LibrariesModule.java new revision: 1.5; previous revision: 1.4 done Checking in libraries/src/org/netbeans/modules/project/libraries/LibrariesStorage.java; /cvs/projects/libraries/src/org/netbeans/modules/project/libraries/LibrariesStorage.java,v <-- LibrariesStorage.java new revision: 1.15; previous revision: 1.14 done |