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: | Assert in FolderObj.getChildren(FolderObj.java:150) | ||
---|---|---|---|
Product: | platform | Reporter: | javydreamercsw <javydreamercsw> |
Component: | Filesystems | Assignee: | Jaroslav Tulach <jtulach> |
Status: | RESOLVED FIXED | ||
Severity: | normal | CC: | abjerkho, aglynn42, AIML_Engr, andreyv, ashwinperti, asmotrich, aussi, BattleWolf, bfenton, bittarman, Blackpanther, bluppy2, budgie67, Chiana, dao, dezagui, dwuysan, emcmanus, esmithbss, exceptions_reporter, floeH, frandevel, FrantaM, freshapple, fzamboj, gawrik, hacenator, henriquemoody, hmichel, host, jasondonmoyer, jeckkech, jlahoda, jskrivanek, kangaroody, karel_barel, kecampbell, mantiss, marcelorodrigo, mfukala, michal.owsiak, mihai, miibx5, minoleg, msandoz, pcdinh, pragalathan, riversy, rknapen, rperazzo, st3vie, stefanv, szmitek, TobiasKranz, tomzi, tzezula, vincentbluff, wholladay, xaguilars |
Priority: | P1 | ||
Version: | 7.0 | ||
Hardware: | All | ||
OS: | All | ||
Issue Type: | DEFECT | Exception Reporter: | 172658 |
Attachments: |
Dump
stacktrace Dump |
Description
javydreamercsw
2010-09-12 22:54:56 UTC
Created attachment 101993 [details]
Dump
Seems like some kind of debugging assert in filesystems. java.lang.AssertionError: FileName: c:\src\src\games\jwrestling\server\core\engine\db\controller\AgeJpaController.java@e810c5 fo: MasterFileObject[c:\src\src\games\jwrestling\server\core\engine\db\controller\AgeJpaController.java@15d134d:14cb66e,valid=true] at masterfs.filebasedfs.fileobjects.FolderObj.getChildren(FolderObj.java:150) at org.openide.filesystems.FileObject.getChildren(FileObject.java:791) at java.source.parsing.SourceFileManager.list(SourceFileManager.java:95) *** Bug 190354 has been marked as a duplicate of this bug. *** *** Bug 190679 has been marked as a duplicate of this bug. *** Making P2, duplicates are counting and counting. *** Bug 191074 has been marked as a duplicate of this bug. *** *** Bug 191142 has been marked as a duplicate of this bug. *** *** Bug 191093 has been marked as a duplicate of this bug. *** *** Bug 191159 has been marked as a duplicate of this bug. *** There seems to be a race condition in allocation of a file name fragments. I have reproduced it in the case where a refresh (caused by external change) was running concurrently with PackageViewChildren. I have added allocation stack traces to FileName and the collision looks like: Assert problem, stack traces: java.lang.Exception: Trace at org.netbeans.modules.masterfs.filebasedfs.naming.FileName.<init>(FileName.java:69) at org.netbeans.modules.masterfs.filebasedfs.naming.NamingFactory.createFileNaming(NamingFactory.java:229) at org.netbeans.modules.masterfs.filebasedfs.naming.NamingFactory.registerInstanceOfFileNaming(NamingFactory.java:172) at org.netbeans.modules.masterfs.filebasedfs.naming.NamingFactory.fromFile(NamingFactory.java:89) at org.netbeans.modules.masterfs.filebasedfs.children.ChildrenSupport.rescanChildren(ChildrenSupport.java:224) at org.netbeans.modules.masterfs.filebasedfs.children.ChildrenSupport.refresh(ChildrenSupport.java:163) at org.netbeans.modules.masterfs.filebasedfs.fileobjects.FolderObj$FolderChildrenCache.refresh(FolderObj.java:588) at org.netbeans.modules.masterfs.filebasedfs.fileobjects.FolderObj.refreshImpl(FolderObj.java:373) at org.netbeans.modules.masterfs.filebasedfs.fileobjects.BaseFileObj.refresh(BaseFileObj.java:750) at org.netbeans.modules.masterfs.filebasedfs.fileobjects.FolderObj.refresh(FolderObj.java:462) at org.openide.filesystems.FileObject.refresh(FileObject.java:1036) at org.netbeans.modules.masterfs.filebasedfs.fileobjects.FileObjectFactory$AsyncRefreshAtomicAction.run(FileObjectFactory.java:794) at org.openide.filesystems.EventControl.runAtomicAction(EventControl.java:125) at org.openide.filesystems.FileSystem.runAtomicAction(FileSystem.java:566) at org.openide.filesystems.FileUtil.runAtomicAction(FileUtil.java:563) at org.netbeans.modules.masterfs.filebasedfs.fileobjects.FileObjectFactory.refreshFromGetter(FileObjectFactory.java:802) at org.netbeans.modules.masterfs.filebasedfs.fileobjects.FileObjectFactory.issueIfExist(FileObjectFactory.java:282) at org.netbeans.modules.masterfs.filebasedfs.fileobjects.FileObjectFactory.getFileObject(FileObjectFactory.java:193) at org.netbeans.modules.masterfs.filebasedfs.fileobjects.FileObjectFactory.getValidFileObject(FileObjectFactory.java:680) at org.netbeans.modules.masterfs.filebasedfs.FileBasedFileSystem.getFileObject(FileBasedFileSystem.java:137) at org.netbeans.modules.masterfs.filebasedfs.FileBasedURLMapper.getFileObjects(FileBasedURLMapper.java:134) at org.netbeans.modules.masterfs.MasterURLMapper.getFileObjects(MasterURLMapper.java:65) at org.openide.filesystems.URLMapper.findFileObject(URLMapper.java:216) at org.openide.filesystems.FileUtil.toFileObject(FileUtil.java:1014) at org.netbeans.modules.masterfs.watcher.Watcher$Ext.refreshRecursively(Watcher.java:128) at org.netbeans.modules.masterfs.ProvidedExtensionsProxy.refreshRecursively(ProvidedExtensionsProxy.java:299) at org.netbeans.modules.masterfs.filebasedfs.fileobjects.FileObjectKeeper.init(FileObjectKeeper.java:105) at org.netbeans.modules.masterfs.filebasedfs.fileobjects.FolderObj.refreshImpl(FolderObj.java:456) at org.netbeans.modules.masterfs.filebasedfs.fileobjects.BaseFileObj.refresh(BaseFileObj.java:750) at org.netbeans.modules.masterfs.filebasedfs.fileobjects.FolderObj.refresh(FolderObj.java:462) at org.openide.filesystems.FileObject.refresh(FileObject.java:1036) at org.netbeans.modules.masterfs.watcher.Watcher$1.run(Watcher.java:190) at org.openide.util.RequestProcessor$Task.run(RequestProcessor.java:1418) at org.openide.util.RequestProcessor$Processor.run(RequestProcessor.java:1960) and: java.lang.Exception: Trace at org.netbeans.modules.masterfs.filebasedfs.naming.FileName.<init>(FileName.java:69) at org.netbeans.modules.masterfs.filebasedfs.naming.FolderName.<init>(FolderName.java:61) at org.netbeans.modules.masterfs.filebasedfs.naming.NamingFactory.createFileNaming(NamingFactory.java:232) at org.netbeans.modules.masterfs.filebasedfs.naming.NamingFactory.registerInstanceOfFileNaming(NamingFactory.java:172) at org.netbeans.modules.masterfs.filebasedfs.naming.NamingFactory.fromFile(NamingFactory.java:89) at org.netbeans.modules.masterfs.filebasedfs.children.ChildrenSupport.rescanChildren(ChildrenSupport.java:224) at org.netbeans.modules.masterfs.filebasedfs.children.ChildrenSupport.getChildren(ChildrenSupport.java:89) at org.netbeans.modules.masterfs.filebasedfs.fileobjects.FolderObj$FolderChildrenCache.getChildren(FolderObj.java:578) at org.netbeans.modules.masterfs.filebasedfs.fileobjects.FolderObj.getChildren(FolderObj.java:138) at org.netbeans.spi.java.project.support.ui.PackageView.findNonExcludedPackages(PackageView.java:191) at org.netbeans.spi.java.project.support.ui.PackageView.findNonExcludedPackages(PackageView.java:219) at org.netbeans.spi.java.project.support.ui.PackageView.findNonExcludedPackages(PackageView.java:163) at org.netbeans.spi.java.project.support.ui.PackageViewChildren.findNonExcludedPackages(PackageViewChildren.java:281) at org.netbeans.spi.java.project.support.ui.PackageViewChildren.computeKeys(PackageViewChildren.java:273) at org.netbeans.spi.java.project.support.ui.PackageViewChildren.run(PackageViewChildren.java:218) at org.openide.util.RequestProcessor$Task.run(RequestProcessor.java:1418) at org.openide.util.RequestProcessor$Processor.run(RequestProcessor.java:1960) *** Bug 191173 has been marked as a duplicate of this bug. *** *** Bug 191199 has been marked as a duplicate of this bug. *** *** Bug 191191 has been marked as a duplicate of this bug. *** *** Bug 191377 has been marked as a duplicate of this bug. *** *** Bug 191395 has been marked as a duplicate of this bug. *** Created attachment 102708 [details]
stacktrace
Created attachment 102730 [details]
Dump
OK, no race condition, NamingFactory.fromFile is correctly synchronized and the subsequent code even asserts the lock held. I have found a bug in the (quite hard to read, unnecessarily many ternary operators used where if() would be much cleaner) code of NamingFactory.registerInstanceOfFileNaming. The conversion from one direct referenced entry to a list of entries forgot to re-add the original entry. The fix alone is a one-liner, though I'm still testing it a bit. Root case identified, covered with a test and fixed: http://hg.netbeans.org/core-main/rev/4835237b24bc *** Bug 191505 has been marked as a duplicate of this bug. *** Thanks for all! *** Bug 191794 has been marked as a duplicate of this bug. *** *** Bug 191682 has been marked as a duplicate of this bug. *** *** Bug 191813 has been marked as a duplicate of this bug. *** Please have a look at report #172658. Bug occred at 201011150001! This is still valid. Take a look at the latest reports. I am not able to reproduce it every time but when switching between Project Groups it happens sometimes. *** Bug 192116 has been marked as a duplicate of this bug. *** Changed Priority to P1. When I select an folder an the exception occures, I doesn´t see any java-File and I can´t open a Java-File. Btw. just run with -da if you are too annoyed by this bug... Rather than switching assertions off, I'd like you to use upgrade to new build and reproduce the failure again. I've enabled dump of allocation stacktraces (slow), but that is probably the only way to find out what is wrong: core-main#2f260f4b8d99 http://statistics.netbeans.org/analytics/exception.do?id=444909 Happened in dev build having Jarda's changes. Integrated into 'main-golden', will be available in build *201011280001* on http://bits.netbeans.org/dev/nightly/ (upload may still be in progress) Changeset: http://hg.netbeans.org/main/rev/2f260f4b8d99 User: Jaroslav Tulach <jtulach@netbeans.org> Log: #190319: Dump allocation stacktrace when the assert fails changeset: f8b5f4a0abde summary: #190319: Dump also content of global map I guess I got one idea of what can be wrong. core-main#6c0055ccd3ed Just uploaded the dump, please see report #445749. Fresh IDE start with some projects loaded, I did not manipulate IDE at all - the assertion happened during the initial project scan. *** Bug 192492 has been marked as a duplicate of this bug. *** *** Bug 122295 has been marked as a duplicate of this bug. *** Integrated into 'main-golden', will be available in build *201011300001* on http://bits.netbeans.org/dev/nightly/ (upload may still be in progress) Changeset: http://hg.netbeans.org/main/rev/f8b5f4a0abde User: Jaroslav Tulach <jtulach@netbeans.org> Log: #190319: Dump also content of global map The assertion seems to fail for a java.hints test in: http://bertram.netbeans.org/hudson/job/jet-main/3235/testReport/junit/org.netbeans.modules.java.hints/IllegalInstanceOfTest/testIssue108246/ In build 3236, there is similar problem for a different test, so this does not seem to be a problem in the tests. The 3235 build contains both 6c0055ccd3ed and f8b5f4a0abde. ergonomics#f568ff70892e Does not appear to be fixed: It has now been added to the database with id #448819. It has been classified as a duplicate of report #172658. This bug was already fixed. Please update your build of NetBeans to the latest build of 7.0 where bug #190319 is fixed. If you are already using a newer build and your report meets certain criteria a new bug will be filed automatically. I am running Build 201012050001 and bug was fixed and integrated in Build 201011300001. Product Version: NetBeans IDE Dev (Build 201012050001) Java: 1.6.0_22; Java HotSpot(TM) 64-Bit Server VM 17.1-b03 System: Linux version 2.6.35-23-generic running on amd64; UTF-8; en_US (nb) changeset is not propagated, i.e. still not in main-silver http://hg.netbeans.org/main-silver/rev/f568ff70892e I've filed P1 issue #192901 which blocks propagation of this fix into production *** Bug 191973 has been marked as a duplicate of this bug. *** *** Bug 192365 has been marked as a duplicate of this bug. *** *** Bug 182898 has been marked as a duplicate of this bug. *** *** Bug 192678 has been marked as a duplicate of this bug. *** Integrated into 'main-golden', will be available in build *201012070001* on http://bits.netbeans.org/dev/nightly/ (upload may still be in progress) Changeset: http://hg.netbeans.org/main/rev/f568ff70892e User: Jaroslav Tulach <jtulach@netbeans.org> Log: #190319: Rather than using WeakHashMap let's implement the hashing manually and have more control over what it does *** Bug 192953 has been marked as a duplicate of this bug. *** *** Bug 193020 has been marked as a duplicate of this bug. *** *** Bug 193019 has been marked as a duplicate of this bug. *** *** Bug 192617 has been marked as a duplicate of this bug. *** *** Bug 193383 has been marked as a duplicate of this bug. *** *** Bug 193961 has been marked as a duplicate of this bug. *** *** Bug 193665 has been marked as a duplicate of this bug. *** *** Bug 194395 has been marked as a duplicate of this bug. *** *** Bug 193698 has been marked as a duplicate of this bug. *** *** Bug 192223 has been marked as a duplicate of this bug. *** *** Bug 192185 has been marked as a duplicate of this bug. *** *** Bug 194932 has been marked as a duplicate of this bug. *** *** Bug 195140 has been marked as a duplicate of this bug. *** *** Bug 195981 has been marked as a duplicate of this bug. *** *** Bug 195800 has been marked as a duplicate of this bug. *** *** Bug 195891 has been marked as a duplicate of this bug. *** *** Bug 196059 has been marked as a duplicate of this bug. *** |