Please use the Apache issue tracking system for new NetBeans 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 QA Contact: issues <>
Priority: P2 CC: anebuzelsky, johnjamesjacoby, jtulach, mmirilovic, saubrecht, tzezula
Version: 7.2   
Target Milestone: 7.2   
Hardware: All   
OS: All   
Issue Type: DEFECT Exception Report:
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(
	at com.sun.jna.Function.invoke(
	at com.sun.jna.Library$Handler.invoke(
	at $Proxy3.CFRunLoopRun(Unknown Source)
	at org.netbeans.modules.masterfs.watcher.macosx.OSXNotifier$
	at java.util.concurrent.ThreadPoolExecutor.runWorker(
	at java.util.concurrent.ThreadPoolExecutor$

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?
(Note: rename the heap_dump file included in the zip to, 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 ***
By use of this website, you agree to the NetBeans Policies and Terms of Use. © 2014, Oracle Corporation and/or its affiliates. Sponsored by Oracle logo