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.
The following issue happens intermittently in the Projects build (20030915). So far I have seen this on two machines (Windows and Linux), but it's quite hard to reproduce. I can reproduce this most reliably by starting with the clean user dir and after deleting the $HOME/Projects directory. To reproduce: 1. Choose Project -> New -> Project... to create a new project 2. Enter some name in the Project name field 3. Press the Browse... button next to the Project Home directory. At this point, the exception in the attachment may occur. Sometimes the exception keeps popping up repeatedly, even to the point that OutOfMemoryError is raised. That's the reason for the high priority. I am filing this against openide not only because the stack trace only contains openide classes, but also because it is hoped that the OpenAPI/core team engineers' expertise in the threading area can be helpful in tracking down this issue.
Created attachment 11640 [details] The stack trace of the exception
Now I was also able to get the thread dump when this happens, just before NetBeans threw OutOfMemoryError. See the attachment.
Created attachment 11657 [details] The thread dump, after the exception was thrown
Looks like a bug in either PropertySheet or in DataObjectPanl
Petr, I think I fixed this issue 2 days ago. Does this happen on the current trunk? I fixed a problem with DataObjectEditor - on a second invocation as a dialog, it was talking to the wrong PropertyEnv object to control the dialog; this resulted in an endless loop inside PropertyPanel since setting the state in its initialization caused the editor to be recreated. So I *think* this is a duplicate and already fixed; let me know if it really still happens.
You are right, I have not seen it on today's build. You may close it as fixed (or duplicate).
Well, actually, I have seen it again in the latest continuous build, although the consequences are not that severe (no OutOfMemoryError or anything). I am attaching the new stack (slightly different from the previous one).
Created attachment 11675 [details] The new stack trace, which still occurs even after Tim's fix.
Ugh. The file chooser uses a separate thread to fetch the list of files to display, but the files are really Nodes, so if something changes while it's trying to fetch them, it dies. The change that precipitated this may have been a change in the timing of when PropertyEnv.setState() is called on initializing the custom editor; I suspect it may have always been broken if something would call setState while the file chooser's file-fetcher thread was running. Or maybe it has nothing to do with setState() on PropertyEnv - if something would fire a change in the Node's children (like slowly recognizing objects in another thread), that would probably trigger this exception. Cleanest way to solve this (and make the whole thing less likely to have other bugs) might be to get rid of the Nodes layer in the various custom editors (it could probably all be done with DataObjects), but that would be a substantial rewrite and given that DataSystems as we know it is going away, that's probably not a good use of time.
Petr, question, since I don't have a projects build handy: Is it the tree DataObjectEditor or the FileChooser DataObjectEditor that is shown when this Browse button is pressed? I'm going to try to create a simplified test case that simply uses underlying DataObjects that are deathly-slow at returning their children, but I need any details you can give. I'm pretty sure this problem has always been there, it's just showing up now because of the performance problems in projects. Also lowering the priority to P3 - since the OOME/endless loop problem is fixed, so it's no longer a showstopper. fixed
I've spent a few hours doing all sorts of strange things with events and threads trying to reproduce this, with no luck. The most useful thing would be an idea who caused the InterruptedException. This is pretty mystifying. I *may* take a stab at rewriting the file chooser UI to not use nodes at all. However, the editor currently allows the property to supply a hint for the root node to use - that would break. As would icons (I could still call getNodeDelegate for that without involving the whole Children threading mess...maybe). Ugh.
I am not quite sure I understand correctly what you are asking, so I am adding Vita to cc:. Is the question whether the editor shows just one current directory, or or an expandable tree of directories? The answer is that it just shows one directory. Re avoiding the nodes layer, wouldn't another solution be to bypass the nodes supplied by Datasystems (getNodeDelegate()) and instead use the LookNodes supplied by filesystem extensions + looks? Admittedly, this would also ditch icons, but if most modules provide a Look for their MIME type, then many icons would be re-added this way.
I think the editor is the FileChooser DataObjectEditor.
Yes, it is DataObjectEditor, but that editor has two possible custom editors depending what hint you pass. But I think it's clear you're using the file chooser editor, not the node tree editor. Using LookNode probably wouldn't help much - the real problem is the (dangerous, complicated, over-synchronized) way Children itself is implemented. I'm looking forward to a Node-free world.
Are we really thinking about deprecating Nodes? I heard this is an option, but this would have far-reaching consequences (even the Window system would be affected), and would put an enormous burden on module writers. Couldn't we instead fix the Children class and its threading problems?
Well, I don't know that it will be done and I don't know when. If they are, it should be supported with a compatibility bridge for some time. But consider: The core problem with Nodes *is* the Children object, and the fact that the child nodes are a de-facto data cache - one that must be kept in sync no matter what thread, where, when or how the data changes. And one that causes gui updates (think: synchronized(getTreeLock()) and deadlocks) when it is updated. Whenever you keep the same data in two places, you pay synchronization costs. And it's not even useful, keeping a cache of data just to hang onto a display name and an icon (this is really all a node is, after all). And it keeps NetBeans from *ever* being scalable - whenever you need to display something you end up creating a huge number of objects - the Node and its supporting children, lookup, lists and other gobbledygook. So in the long run, no matter how much fixing of Children we do, it will never work well enough. A Look, on the other hand is a slight abstraction on having a per-type utility class that can answer the question "what's the icon for this?", "what's the display name for this." So you have one-or-less extra objects per type of thing you want to represent in explorer, instead of a minimum of several extra objects per instance of a type.
I see, yes this sounds like a problem. But would not it be possible to deprecate the use of Nodes as SPI (i.e. discourage creating own subclasses of Node and the use of Children.Keys) while preserving the use of Nodes as API, e.g. by the window system (possibly with just low-impact incompatible changes, such as factoring out code from Children and allowing subclasses of Children which do not behave like a cache). That way LookNode would be the preferred implementation of Node with own efficient implementation of Children, and Nodes as API would be preserved.
Maybe - it's not my decision. I do notice, though, that most deadlocks I see reported involve Children objects; and after using the JList that renders a look directly that I wrote for the Navigator module, and finding it's fast, problem free and the most that any change means is that you need to repaint, I have a hard time justifying the overhead of Nodes in my mind anymore. Anyway, we need to fix this bug, not discuss philosophy :-)
As described in http://www.netbeans.org/servlets/ReadMsg?msgId=619519&listName=nbdiscuss the current work on projects prototype has been stopped. This issue should be closed or tracked as non Projects issues. removed PROJECTS keyword.
DataObjectEditor should be killed at the earliest possible time, the filechooser UI possibly sooner. No further work is planned on DataObjectEditor or DataFolderEditor. At best, it can never be made reliable; further changes are only likely to introduce additional problems. See my comments at the end of issue 38469 for details.
closed