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.

Bug 212687

Summary: OutOfMemoryError and high CPU load and crash
Product: platform Reporter: Petr Jiricka <pjiricka>
Component: Options&SettingsAssignee: Theofanis Oikonomou <theofanis>
Status: RESOLVED DUPLICATE    
Severity: normal CC: anebuzelsky, johnjamesjacoby, jtulach, mmirilovic, saubrecht, tzezula
Priority: P2    
Version: 7.2   
Hardware: All   
OS: All   
URL: http://netbeans.org/projects/profiler/downloads/download/Heapdumps/heapdump_212687.hprof.gz
Issue Type: DEFECT Exception Reporter:
Attachments: Thread dump + some more diagnostic information
IDE log file
HotSpot crash file (hs_err_pid1002.log)

Description Petr Jiricka 2012-05-18 08:40:47 UTC 
I was in the middle of a file creation wizard, when the IDE generated a high CPU load (~170% CPU load on a dual-core machine) and went out of memory. Shortly after that, the IDE crashed. I am attaching a thread dump while the IDE had high CPU load (before the crash), the IDE log file and the HotSpot crash file. I also have a heap dump generated by the JVM when it went out of memory (960 MB).
Comment 1 Petr Jiricka 2012-05-18 08:42:24 UTC 
Created attachment 119598 [details]
Thread dump + some more diagnostic information
Comment 2 Petr Jiricka 2012-05-18 08:42:50 UTC 
Created attachment 119600 [details]
IDE log file
Comment 3 Petr Jiricka 2012-05-18 08:43:27 UTC 
Created attachment 119601 [details]
HotSpot crash file (hs_err_pid1002.log)
Comment 4 Stanislav Aubrecht 2012-05-18 09:30:05 UTC 
I can't find anything suspicious in the logs. Perhaps the JDK team should analyze the crash log.
Comment 5 Petr Jiricka 2012-05-18 12:12:53 UTC 
You are right that the JDK team should look at the crash, but the OOME problem is likely in NetBeans.
Comment 6 Antonin Nebuzelsky 2012-05-24 21:01:36 UTC 
Hotspot crash log says "Thread-3" has crashed. According to the thread dump it is in JNA's calls for native file listening.

Thread-3" daemon prio=5 tid=0x00007f8333791000 nid=0x11f7d4000 runnable [0x000000011f7d3000]
   java.lang.Thread.State: RUNNABLE
	at com.sun.jna.Native.invokeVoid(Native Method)
	at com.sun.jna.Function.invoke(Function.java:328)
	at com.sun.jna.Function.invoke(Function.java:276)
	at com.sun.jna.Library$Handler.invoke(Library.java:216)
	at $Proxy3.CFRunLoopRun(Unknown Source)
	at org.netbeans.modules.masterfs.watcher.macosx.OSXNotifier$1.run(OSXNotifier.java:126)
	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110)
	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603)
	at java.lang.Thread.run(Thread.java:722)

Tomasi, Jardo, please evaluate.
Comment 7 Antonin Nebuzelsky 2012-05-24 21:16:07 UTC 
*** Bug 212612 has been marked as a duplicate of this bug. ***
Comment 8 Tomas Zezula 2012-06-01 06:49:59 UTC 
The OSXNotifier just calls CFRunLoopRun()V.
JNA issue.
Comment 9 Tomas Zezula 2012-06-01 06:57:39 UTC 
I may be also VM failure.
The  JNA correctly called the Core Foundation CFRunLoopRun which crashed in libjvm.dylib called back by JNA (create_callback).
Has anyone the core dump?
Comment 10 Petr Jiricka 2012-06-01 09:47:18 UTC 
I have a head dump shortly before the crash, does that help?
http://deadlock.netbeans.org/hudson/job/heap_dumps/ws/Issue212687_2012-06-01_02-02-55_1dcfe016b3a3f1255be98bc6f91d1496.zip
(Note: rename the heap_dump file included in the zip to heap_dump.zip, as it is itself a zip containing file heapdump.hprof.)
Comment 11 Tomas Zezula 2012-06-01 11:05:59 UTC 
Unortunately the heap dump is useless the core dump is needed to find out in gdb if it's jna o jvm issue.
Comment 12 Petr Jiricka 2012-06-04 07:32:30 UTC 
As I wrote, this bug is not only about VM crash - the crash was preceded by an OOME. I filed that as a separate bug 213482.
Comment 13 Tomas Hurka 2012-06-12 09:16:43 UTC 

*** This bug has been marked as a duplicate of bug 213860 ***