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 200410725 JDK 1.5 On startup, I got the attached exception
Created attachment 18183 [details] Stack-trace
Consistently? Occasionally? Once? Any steps whatsoever to reproduce? The exception is inside Xerces DOM code, not NB code, so it will be hard to do much with it unless more information becomes available.
I got it once. No idea how to reproduce it, sorry.
No, I really meant TBD as the milestone, not 4.1. I don't know what this exception means or how to reproduce it, so I can't guarantee it will be fixed at any particular time. Closing for now, let's see if it happens again (in the 4.0 release or a current dev build).
Does not appear to have gone away, unfortunately. Still no clue about it.
*** Issue 51677 has been marked as a duplicate of this issue. ***
*** Issue 50941 has been marked as a duplicate of this issue. ***
Looking at the source-code for org.apache.xerces.dom.ParentNode.nodeListItem(ParentNode:814) it looks like a threading problem to me. According to the documentation right above it: // we can keep using the cache until it is actually reused // fNodeListCache will be nulled by the pool (document) if that // happens. // fNodeListCache = null; which leads me to believe that we invoke code on one branch which causes the cache to be nulled and try using that same cache entry on another thread and that other thread throws NPE.
Quite possible... the question is which two threads those are. All code loading or storing project.xml fragments is supposed to be controlled by one ProjectManager.mutex() (in shared read or exclusive write mode). You *can* work with fragments outside of the mutex (poor style), but it shouldn't make any difference because you should always be using a clone of the DOM fragment, not the original (AntProjectHelper should enforce this).
Jesse, Can we not scan the Netbeans code for all references to org.netbeans.modules.project.ant.Util.findElement() and code-review them? I'm not sure how many such references exist but it's an idea.
Yes, that would be the place to start...
*** Issue 56020 has been marked as a duplicate of this issue. ***
Also see issue #46999 and http://www.xml-xerces.com/msg/2734.html.
Food for thought: if we move from Xerces to say dom4j or xom won't this problem go away? Last time I checked, using either of the aforementioned APIs actually simplifies the code and improves performance. See these performance benchmarks: http://www.dom4j.org/benchmarks/xpath/index.html
*** Issue 46999 has been marked as a duplicate of this issue. ***
Using DOM4J, XOM, JDOM, etc. would surely make the code much simpler to read and write; we would have done so long ago except it means we would need to spend the effort to convince lawyers to let us host the library. It is still an option, just on the back burner. Anyway I don't think that's necessarily related to this bug. Thanks for finding the Xerces issue report, that should be helpful.
dom4j uses the BSD license. Why would lawyers have problems with that? The only legal implications are that we have to give them credit for using their library (we already do this for other dependencies) and include the BSD license in our binary distribution. I'm just reading http://www.dom4j.org/license.html
I know BSD license is rather liberal, but we still have to go through an approval process for *any* 3rd-party code, and it can take a while. Encountered exception just from opening nbbuild/misc umbrella project - dev build, JDK 1.6.
*** Issue 57209 has been marked as a duplicate of this issue. ***
Increasing priority to P2 (accoring to duplicate issue 57209 priority) - it is very often (30-50%) in Web/EJB freeform projects on shared disks (I think we should support shared disks, right?).
Well I have a patch which may help. Unfortunately I am not able to reproduce this bug so I can't be sure.
committed Up-To-Date 1.28 ant/project/src/org/netbeans/spi/project/support/ant/AntProjectHelper.java May be fixed now. Not trivial - it is necessary to 1. Always return a full copy of XML fragments to outside code - not just using cloneNode, but making a copy into a fresh owner Document. This may be a bit slower than the old code, though I tried to optimize it by keeping a DocumentBuilder prepared (using XMLUtil.createDocument is much too slow since creating a new DB is apparently expensive). 2. Guard all accesses, even reads, to the "master" copies of the XML trees against multithreaded access. Could be merged if someone can manage to verify that it indeed prevents the reported bug, and if there do not seem to be any side-effects (e.g. new deadlocks from the added synchronization).
Not to be evil, but I'm hearing things like "worse performance" and it sets off warning bells in my head. Any progress with the lawyers and dom4j license?
dom4j is irrelevant here (would likely take at least as much time to copy a tree as Xerces DOM does) and we are certainly not using it for 4.1.
I've seen that issue twice during the last two days. Just Starting up NetBeans, opening one project folder and bang. I really hope it is gonna be fixed for 4.1 Thanks, Cedric java.lang.NullPointerException at com.sun.org.apache.xerces.internal.dom.ParentNode.nodeListItem(ParentNode.java:814) at com.sun.org.apache.xerces.internal.dom.ParentNode.item(ParentNode.java:828) at org.netbeans.modules.ant.freeform.spi.support.Util.findElement(Util.java:61) at org.netbeans.modules.ant.freeform.ui.View$RootChildren.createNodes(View.java:156) at org.openide.nodes.Children$Keys$KE.nodes(Children.java:2050) at org.openide.nodes.ChildrenArray.nodesFor(ChildrenArray.java:112) at org.openide.nodes.Children$Info.nodes(Children.java:1137) at org.openide.nodes.Children.justComputeNodes(Children.java:638) at org.openide.nodes.ChildrenArray.nodes(ChildrenArray.java:54) at org.openide.nodes.Children.getNodes(Children.java:331) at org.openide.nodes.FilterNode$ChildrenAdapter.run(FilterNode.java:1387) at org.openide.nodes.FilterNode$Children.updateKeys(FilterNode.java:1343) at org.openide.nodes.FilterNode$Children.addNotifyImpl(FilterNode.java:1240) at org.openide.nodes.FilterNode$Children.addNotify(FilterNode.java:1232) at org.openide.nodes.Children.callAddNotify(Children.java:426) at org.openide.nodes.Children.getArray(Children.java:476) at org.openide.nodes.Children.getNodes(Children.java:322) at org.openide.explorer.view.VisualizerNode.getChildren(VisualizerNode.java:192) at org.openide.explorer.view.VisualizerNode.getChildCount(VisualizerNode.java:231) at javax.swing.tree.DefaultTreeModel.getChildCount(DefaultTreeModel.java:168) at javax.swing.tree.VariableHeightLayoutCache$TreeStateNode.expand(VariableHeightLayoutCache.java:1461) at javax.swing.tree.VariableHeightLayoutCache$TreeStateNode.expand(VariableHeightLayoutCache.java:1270) at javax.swing.tree.VariableHeightLayoutCache.ensurePathIsExpanded(VariableHeightLayoutCache.java:966) at javax.swing.tree.VariableHeightLayoutCache.setExpandedState(VariableHeightLayoutCache.java:164) at javax.swing.plaf.basic.BasicTreeUI.updateExpandedDescendants(BasicTreeUI.java:1542) at javax.swing.plaf.basic.BasicTreeUI$Handler.treeExpanded(BasicTreeUI.java:3578) at javax.swing.JTree.fireTreeExpanded(JTree.java:2235) at javax.swing.JTree.setExpandedState(JTree.java:3006) at javax.swing.JTree.expandPath(JTree.java:1742) at javax.swing.plaf.basic.BasicTreeUI.toggleExpandState(BasicTreeUI.java:2149) at javax.swing.plaf.basic.BasicTreeUI.handleExpandControlClick(BasicTreeUI.java:2136) at javax.swing.plaf.basic.BasicTreeUI.checkForClickInExpandControl(BasicTreeUI.java:2090) at javax.swing.plaf.basic.BasicTreeUI$Handler.handleSelection(BasicTreeUI.java:3423) at javax.swing.plaf.basic.BasicTreeUI$Handler.mousePressed(BasicTreeUI.java:3393) at java.awt.AWTEventMulticaster.mousePressed(AWTEventMulticaster.java:222) at java.awt.AWTEventMulticaster.mousePressed(AWTEventMulticaster.java:221) at java.awt.AWTEventMulticaster.mousePressed(AWTEventMulticaster.java:221) at java.awt.AWTEventMulticaster.mousePressed(AWTEventMulticaster.java:221) at java.awt.AWTEventMulticaster.mousePressed(AWTEventMulticaster.java:221) at java.awt.Component.processMouseEvent(Component.java:5485) at javax.swing.JComponent.processMouseEvent(JComponent.java:3093) at java.awt.Component.processEvent(Component.java:5253) at java.awt.Container.processEvent(Container.java:1966) at java.awt.Component.dispatchEventImpl(Component.java:3955) at java.awt.Container.dispatchEventImpl(Container.java:2024) at java.awt.Component.dispatchEvent(Component.java:3803) at java.awt.LightweightDispatcher.retargetMouseEvent(Container.java:4212) at java.awt.LightweightDispatcher.processMouseEvent(Container.java:3889) at java.awt.LightweightDispatcher.dispatchEvent(Container.java:3822) at java.awt.Container.dispatchEventImpl(Container.java:2010) at java.awt.Window.dispatchEventImpl(Window.java:1766) at java.awt.Component.dispatchEvent(Component.java:3803) [catch] at java.awt.EventQueue.dispatchEvent(EventQueue.java:463) at java.awt.EventDispatchThread.pumpOneEventForHierarchy(EventDispatchThread.java:234) at java.awt.EventDispatchThread.pumpEventsForHierarchy(EventDispatchThread.java:163) at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:157) at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:149) at java.awt.EventDispatchThread.run(EventDispatchThread.java:110)
I'm using 200504031800 Actually, the stack trace looks different... Is that the same bug or should I open another one?
"I've seen that issue twice during the last two days": using a trunk (4.2 dev) build, or a 4.1 build? I attempted to fix it in the trunk, not yet the 4.1 branch, because I have not received any feedback yet as to whether the patch actually fixes the problem. (The stack trace does look like this bug. The exact form of the stack trace will vary a bit but the top should always involve these Xerces internal classes.)
That's an april 3 (200504031800) so I think it was the last snapshot before the branch was created. Cedric
Well the intended fix only made it into the trunk after the branch.
Yes, so I think it is worth putting that fix on the branch. Because otherwise, 4.1 is gonna be a bad release. I could test the trunc to see if that bug has disappeared, but since it appends only once a day so far (meaning every 20 restart or so) It would be hard for me to be sure that the bug is really gone.... And I want to focus my testing on the release branch, that's the goal :) So if you put the fix in the branch, I will download and use a new snapshot and 10 days from now I've not seen this bug anymore, then there is a good chance it was fixed. Or are you waiting for something else before?
Jesse, please prepare a binary patch for 4.1, so that we can ask QA and other people to test with it. Thanks.
Probably to be fixed in 4.1; still awaiting more thorough testing.
Seems OK - I have tested my scenario from issue 57209 in build 200504061800 (on WebFreeform) and I'm not able to reproduce. I haven't seen any other regression of this fix so far. Milan Kubec tested JavaFreeform in trunk today too and hasn't seen any other regressions too. The fix is ready for integration into release41 branch from QE point of view.
Sounds good. Tomas Z., could I get a code review for this? After David K. you're probably the person most familiar with usage of AntProjectHelper.
The fix seems good to me. It synchronize the access to XML documents and also creates a new XML document rather than cloning node. It should fix this issue.
Checking in ant/project/src/org/netbeans/spi/project/support/ant/AntProjectHelper.java; /cvs/ant/project/src/org/netbeans/spi/project/support/ant/AntProjectHelper.java,v <-- AntProjectHelper.java new revision: 1.27.14.1; previous revision: 1.27 done
I've just installed NB 4.2-dev snapshot 200504111800 And I've got the same exception I mentionned in comment I mentionned on my Wed Apr 6 15:31:07 comment the very first time I used 4.2-dev. What I did is: 1) Open NB. 2) Close all projects 3) Open other projects 4) On the "Projects" view, click on the + icon to open the project content. At this time, that ugly NPE occured, and there was no "Source Files" nor "Test Files" in my project. Closing the project and reopening it fixed the problem. So I fear that this bug is still there.
java.lang.NullPointerException at com.sun.org.apache.xerces.internal.dom.ParentNode.nodeListGetLength(ParentNode.java:745) at com.sun.org.apache.xerces.internal.dom.ParentNode.getLength(ParentNode.java:757) at org.netbeans.modules.ant.freeform.spi.support.Util.findElement(Util.java:60) at org.netbeans.modules.ant.freeform.ui.View$RootChildren.createNodes(View.java:156) at org.openide.nodes.Children$Keys$KE.nodes(Children.java:2050) at org.openide.nodes.ChildrenArray.nodesFor(ChildrenArray.java:112) at org.openide.nodes.Children$Info.nodes(Children.java:1137) at org.openide.nodes.Children.justComputeNodes(Children.java:638) at org.openide.nodes.ChildrenArray.nodes(ChildrenArray.java:54) at org.openide.nodes.Children.getNodes(Children.java:331) at org.openide.nodes.FilterNode$ChildrenAdapter.run(FilterNode.java:1387) at org.openide.nodes.FilterNode$Children.updateKeys(FilterNode.java:1343) at org.openide.nodes.FilterNode$Children.addNotifyImpl(FilterNode.java:1240) at org.openide.nodes.FilterNode$Children.addNotify(FilterNode.java:1232) at org.openide.nodes.Children.callAddNotify(Children.java:426) at org.openide.nodes.Children.getArray(Children.java:476) at org.openide.nodes.Children.getNodes(Children.java:322) at org.openide.explorer.view.VisualizerNode.getChildren(VisualizerNode.java:192) at org.openide.explorer.view.VisualizerNode.getChildCount(VisualizerNode.java:231) at javax.swing.tree.DefaultTreeModel.getChildCount(DefaultTreeModel.java:168) at javax.swing.tree.VariableHeightLayoutCache$TreeStateNode.expand(VariableHeightLayoutCache.java:1461) at javax.swing.tree.VariableHeightLayoutCache$TreeStateNode.expand(VariableHeightLayoutCache.java:1270) at javax.swing.tree.VariableHeightLayoutCache.ensurePathIsExpanded(VariableHeightLayoutCache.java:966) at javax.swing.tree.VariableHeightLayoutCache.setExpandedState(VariableHeightLayoutCache.java:164) at javax.swing.plaf.basic.BasicTreeUI.updateExpandedDescendants(BasicTreeUI.java:1542) at javax.swing.plaf.basic.BasicTreeUI$Handler.treeExpanded(BasicTreeUI.java:3578) at javax.swing.JTree.fireTreeExpanded(JTree.java:2235) at javax.swing.JTree.setExpandedState(JTree.java:3006) at javax.swing.JTree.expandPath(JTree.java:1742) at javax.swing.plaf.basic.BasicTreeUI.toggleExpandState(BasicTreeUI.java:2149) at javax.swing.plaf.basic.BasicTreeUI.handleExpandControlClick(BasicTreeUI.java:2136) at javax.swing.plaf.basic.BasicTreeUI.checkForClickInExpandControl(BasicTreeUI.java:2090) at javax.swing.plaf.basic.BasicTreeUI$Handler.handleSelection(BasicTreeUI.java:3423) at javax.swing.plaf.basic.BasicTreeUI$Handler.mousePressed(BasicTreeUI.java:3393) at java.awt.AWTEventMulticaster.mousePressed(AWTEventMulticaster.java:222) at java.awt.AWTEventMulticaster.mousePressed(AWTEventMulticaster.java:221) at java.awt.AWTEventMulticaster.mousePressed(AWTEventMulticaster.java:221) at java.awt.AWTEventMulticaster.mousePressed(AWTEventMulticaster.java:221) at java.awt.AWTEventMulticaster.mousePressed(AWTEventMulticaster.java:221) at java.awt.Component.processMouseEvent(Component.java:5485) at javax.swing.JComponent.processMouseEvent(JComponent.java:3093) at java.awt.Component.processEvent(Component.java:5253) at java.awt.Container.processEvent(Container.java:1966) at java.awt.Component.dispatchEventImpl(Component.java:3955) at java.awt.Container.dispatchEventImpl(Container.java:2024) at java.awt.Component.dispatchEvent(Component.java:3803) at java.awt.LightweightDispatcher.retargetMouseEvent(Container.java:4212) at java.awt.LightweightDispatcher.processMouseEvent(Container.java:3889) at java.awt.LightweightDispatcher.dispatchEvent(Container.java:3822) at java.awt.Container.dispatchEventImpl(Container.java:2010) at java.awt.Window.dispatchEventImpl(Window.java:1766) at java.awt.Component.dispatchEvent(Component.java:3803) [catch] at java.awt.EventQueue.dispatchEvent(EventQueue.java:463) at java.awt.EventDispatchThread.pumpOneEventForHierarchy(EventDispatchThread.java:234) at java.awt.EventDispatchThread.pumpEventsForHierarchy(EventDispatchThread.java:163) at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:157) at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:149) at java.awt.EventDispatchThread.run(EventDispatchThread.java:110)
Well, I'm out of ideas, unless someone comes up with a reliable way to reproduce it. (Or someone who can often reproduce it on their own machine spends some time tracking it down in a debugger or using println's or something.) Anyone besides cberger see it recently?
cberger, could you try again with a freshly downloaded 4.2 dev build and make sure you still see the bug, even with the updated code? Just want to make sure you aren't accidentally using an older dev build or something. Thanks in advance.
I'm pretty sure that the latest trace I reported was with a 4.2 build, but OK, I see that there is a new 200504121800 4.2 build, so I will download it and install it tommorow morning, and a I'll report back. But note that this exception is random, I've got it only 3 or 4 times total during the last two weeks. I usually just get it after starting NB the first time, which mean that if I don't see the exception tommorow, this is not conclusive (my workstation is dual-cpu, which may explain why I'm more sensitive to race) Have you look at the line number of the last stack trace I posted? I noticed that they are quite different from the first one. On April 6 (NB 4.1), it started with: com.sun.org.apache.xerces.internal.dom.ParentNode.nodeListItem(ParentNode.java:814) at com.sun.org.apache.xerces.internal.dom.ParentNode.item(ParentNode.java:828) at org.netbeans.modules.ant.freeform.spi.support.Util.findElement(Util.java:61) at but on April 12 (with I believe NB 4.2) it started with com.sun.org.apache.xerces.internal.dom.ParentNode.nodeListGetLength(ParentNode.java:745) at com.sun.org.apache.xerces.internal.dom.ParentNode.getLength(ParentNode.java:757) at org.netbeans.modules.ant.freeform.spi.support.Util.findElement(Util.java:60) maybe by checking these line number you could confirm that I tested the right build?
The exact stack trace doesn't mean that much to me - the (attempted) fix just corrects apparent misuses of threading in the NB code which calls into the Xerces DOM in general. Without a reproducible test case, there is no easy way to prove that the Xerces stack traces were caused by improper access from multiple threads; that is just the likeliest guess. Someone from Sun will try again to reproduce the bug both in an old and a new dev build. I agree that use of a dual-CPU machine could help increase the likelihood of observing the bug, though it was also known to occur on a single-CPU machine.
What I was saying about stack trace is that maybe by looking at the line numbers, you could see if it was taken by a 4.1 or 4.2 build (I suspect code has moved between 4.1 and 4.2), just to confirm that I did not test 4.1 instead of a 4.2 build by mistake.
Won't help. The exception is not thrown directly from the code which had to be patched - it is thrown from unrelated code which uses a data structure it obtained from the code that had to be patched. I.e. I believe it works like this: if client code C1 calls AntProjectHelper (the patched code; call it APH) to get a DOM fragment at time 0 in thread T1 and then uses that DOM at time 2, and nothing else was going on, then no problem. But if client code C2 calls APH at say time 1 in thread T2 and also tries to use the DOM it got at time 2, one of C1 or C2 might receive the exception randomly. The patch attempts to give C1 and C2 completely independent copies of the DOM tree so they do not interfere with one another - what I thought cloneNode() did, but apparently in Xerces cloned nodes still share internal data structures used for caches. Ideally Xerces' DOM would be more robust, like java.util.* collections, and give you some detailed information about which threads are attempting to share the same DOM fragment illegally; but this does not seem to be the case. BTW I think there is an implementation feature in Xerces that could be used to prevent the problem even when using cloneNode: http://apache.org/xml/features/dom/defer-node-expansion This is just a URI, *not* a functional hyperlink; see http://xml.apache.org/xerces2-j/features.html but it is certainly better to use Document.importNode and avoid the problem without relying on a semidocumented implementation detail like this.
I've downloaded 200504131800 4.2 daily, and have not got the exception so far. Unfortunately, that doesn't say much. You can close the issue, and I'll reopen it if/when I get the next NPE...
From QE point of view I'd like to see this Fix integration into release41 branch because it helped at least in my reproducible steps.
OK... hope cberger's exception was not really coming from a 4.2 build.
Sorry, the fix was already merged.
*** Issue 58193 has been marked as a duplicate of this issue. ***