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).
Created attachment 119598 [details]
Thread dump + some more diagnostic information
Created attachment 119600 [details]
IDE log file
Created attachment 119601 [details]
HotSpot crash file (hs_err_pid1002.log)
I can't find anything suspicious in the logs. Perhaps the JDK team should analyze the crash log.
You are right that the JDK team should look at the crash, but the OOME problem is likely in NetBeans.
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]
at com.sun.jna.Native.invokeVoid(Native Method)
at $Proxy3.CFRunLoopRun(Unknown Source)
Tomasi, Jardo, please evaluate.
*** Bug 212612 has been marked as a duplicate of this bug. ***
The OSXNotifier just calls CFRunLoopRun()V.
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?
I have a head dump shortly before the crash, does that help?
(Note: rename the heap_dump file included in the zip to heap_dump.zip, as it is itself a zip containing file heapdump.hprof.)
Unortunately the heap dump is useless the core dump is needed to find out in gdb if it's jna o jvm issue.
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.
*** This bug has been marked as a duplicate of bug 213860 ***
Head dump is available at http://netbeans.org/projects/profiler/downloads/download/Heapdumps/heapdump_212687.hprof.gz