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.
After few minutes of normal work in a PHP project netbeans freezes (Typically after entering '$' but not only). It never returns to operate and must be force-closed manually. Call stack: java.lang.OutOfMemoryError: unable to create new native thread at java.lang.Thread.start0(Native Method) at java.lang.Thread.start(Thread.java:597) at org.openide.util.RequestProcessor$Processor.get(RequestProcessor.java:925) at org.openide.util.RequestProcessor.enqueue(RequestProcessor.java:467) at org.openide.util.RequestProcessor$Task.schedule(RequestProcessor.java:635) at org.openide.util.RequestProcessor.post(RequestProcessor.java:296) at org.openide.util.RequestProcessor.post(RequestProcessor.java:267) at org.netbeans.spi.editor.completion.support.AsyncCompletionTask.performQuery(AsyncCompletionTask.java:174) at org.netbeans.spi.editor.completion.support.AsyncCompletionTask.query(AsyncCompletionTask.java:127) at org.netbeans.modules.editor.completion.CompletionImpl.queryResultSets(CompletionImpl.java:1533) at org.netbeans.modules.editor.completion.CompletionImpl.access$400(CompletionImpl.java:102) at org.netbeans.modules.editor.completion.CompletionImpl$3.actionPerformed(CompletionImpl.java:230) at javax.swing.Timer.fireActionPerformed(Timer.java:271) at javax.swing.Timer$DoPostEvent.run(Timer.java:201) at java.awt.event.InvocationEvent.dispatch(InvocationEvent.java:209) at java.awt.EventQueue.dispatchEvent(EventQueue.java:597) at org.netbeans.core.TimableEventQueue.dispatchEvent(TimableEventQueue.java:104) [catch] at java.awt.EventDispatchThread.pumpOneEventForFilters(EventDispatchThread.java:269) at java.awt.EventDispatchThread.pumpEventsForFilter(EventDispatchThread.java:184) at java.awt.EventDispatchThread.pumpEventsForHierarchy(EventDispatchThread.java:174) at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:169) at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:161) at java.awt.EventDispatchThread.run(EventDispatchThread.java:122) java.lang.OutOfMemoryError: unable to create new native thread at java.lang.Thread.start0(Native Method) at java.lang.Thread.start(Thread.java:597) at java.awt.EventQueue.initDispatchThread(EventQueue.java:833) at java.awt.EventDispatchThread.run(EventDispatchThread.java:153) SEVERE [org.openide.util.Exceptions] java.lang.OutOfMemoryError: unable to create new native thread at java.lang.Thread.start0(Native Method) at java.lang.Thread.start(Thread.java:597) at java.awt.EventQueue.initDispatchThread(EventQueue.java:833) [catch] at java.awt.EventDispatchThread.run(EventDispatchThread.java:153)
Created attachment 89423 [details] Messages log of a crash
Created attachment 89426 [details] Another log of a crash, this time using the project window
Created attachment 89429 [details] Just another crash log
Raising priority to P2 to try focus attention on this problem as is making the IDE unusable for my. Can't work more than 10 minutes without a crash.
Not sure it's for editor or php. Could you please evaluate?
Could you please generate a heapdump and either attach it here or upload it to editor.netbeans.org -> Files? For instructions please see http://wiki.netbeans.org/FaqMemoryDump. Thanks
java.lang.OutOfMemoryError: unable to create new native thread Using Google gives me these interesting articles: http://www.egilh.com/blog/archive/2006/06/09/2811.aspx http://puchaanirudh.blogspot.com/2008/04/javalangoutofmemoryerror-unable-to.html http://java-monitor.com/forum/showthread.php?t=570 but assigning the issue to some more hard core members of our team ;-)
@dstrupl: I've already walked this path :-) no results. Besides, is the first time I encounter this problems and been using netbeans for years. @vstejskal: I have configured the editor as to lauch a heap dump. But for some reason is not dumping anything. I'll visit the Wiki and try to make it dump it. @ppis: I'm pretty positive it's not a PHP issue as it arise no matter what are you doing to the IDE.
It seems that IDE just freezes. I've already configured it to produce a heap-dump but it seems it doesn't like if the freeze would prevent java from dumping. I will append the new log.
Created attachment 89446 [details] Log after configure it to produce a heap-dump
Please use jmap to produce the head dump. Without it we cannot find out, what is occupying the memory
*** Bug 179250 has been marked as a duplicate of this bug. ***
Reopening since Bug 179250 has been marked as duplicate. It contains steps to reproduce.
From the duplicate (if it is the same problem) the problem is not in the heap but in the number of threads. All the threads are created as "Inactive RequestProcessor thread [Was:Asynch children creator org.openide.nodes.AsynchChildren@6bb0c6/org.openide.nodes.AsynchChildren]" daemon prio=2 tid=0x08400000 nid=0x1f58 in Object.wait() [0x7f0af000..0x7f0afd14] java.lang.Thread.State: TIMED_WAITING (on object monitor) at java.lang.Object.wait(Native Method) at org.openide.util.RequestProcessor$Processor.run(RequestProcessor.java:1037) - locked <0x1552d6c0> (a java.lang.Object) Locked ownable synchronizers: - None So the problem is not "out of memory" but "too many threads spawned" (as the exception correctly states at the very fitst line. Assigning to Nodes for evaluation.
Changing (clipping) the summary to better reflect the cause of the problem.
Davide, I do not understand reasons why this bug shall belong to nodes. Looks like some unknown problem with memory. Can you please provide better explanation for me, if you want to reassign back?
Now I see the log: https://netbeans.org/bugzilla/attachment.cgi?id=93096 Yes, there is really a lot of RP threads. The problem is that AsynchChildren don't use static RP, but per instance one. Tim, this seems to be your code: changeset: d2839a7616a0 user: tboudreau@netbeans.org date: Sat Jun 02 03:46:54 2007 +0000 summary: #91529 - API for asynchronously computed child nodes. Can you fix it (by making the field static)?
When I saw the summary, I figured that's what it would be. What is bizarre is - how do you manage to be expanding so many nodes at once that you actually run out of OS-level threads? I am more inclined to think that perhaps a lot of ChildFactory instances are furiously calling refresh() aggressively, on creation - or they are searching through Nodes, calling getNodes(true) for a large number of Nodes simultaneously (when they should be querying the underlying data model) i.e. somebody is not using the API correctly. That would trigger a large number of threads being created at the same time; I don't think a person could expand nodes by hand fast enough to run the OS out of available threads by hand. I have changed the thread pool to be global, with 4 threads maximum. But I am pretty sure somebody is misusing the API (or your system has a weirdly low limit for total number of OS-level threads possible). If you could get a dev build tomorrow or so, and run netbeans -J-Dorg.openide.nodes.AsynchChildren.level=ALL and do what you did before, and attach your log file here, we can get some stack traces and confirm if that is what is happening. If so, I can find a more appropriate fix, in the php module. What I have done here will throttle it and should solve the problem, but it does mean if several very slow nodes are expanded at the same time, it will block all others, and I don't like that as a solution. Fixed in main/ 0532c625e554
Integrated into 'main-golden', will be available in build *201001240200* on http://bits.netbeans.org/dev/nightly/ (upload may still be in progress) Changeset: http://hg.netbeans.org/main/rev/0532c625e554 User: Tim Boudreau <tboudreau@netbeans.org> Log: #174524 - in PHP projects, so many AsynchChildren get simultaneously asked for their children that the OS runs out of native threads; I suspect the real bug is in the PHP module - it should be humanly impossible to expand that many nodes at once through the UI - something is doing it programmatically.
*** Bug 170935 has been marked as a duplicate of this bug. ***