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.
I have a multi-threaded application that fetches data from a remote source, and when I try and dump the heap to examine it, the hot spot jvm crashes. As near as I can tell, it is not the threads that fetch the data that cause the crash, but the threads (or the thread pool that is used) that are currently running to process the data fetched. It occurs immediately after I hit the Dump Heap button. This happens constantly every single time I have attempted this. The URL included is a pastebin with 3 of the crashes, and I am keeping the other logs around if needed.
Is it reproducible? Could you describe the type of profiling you use and attach messages.log?
The JDK crash, according to the URL you attached, looks to me like JDK bug. I do not see anything wrong on profiler side.
drizzt321, do you have any new information on this issue? Did you try running the target application with a different JVM (1.5.0_16 or 1.6 eg.) According to the crash log the crash happens inside JVM when taking the heapdump.
I have a very similar (not to say duplicate) issue here: #128107 I'm able to consistently reproduce it on a clean install of jdk_1.5_16_netbeans_6.1 bundle. It happens whenever I'm trying to make a memory heap dump. The funny thing is, when I ask for a memory heap dump (say in the middle of cpu profiling session), netbeans starts to instrument my classes (i.e. outputs to console things like "100 classes instrumented"), though I didn't ask for class instrumentation, just memory heap dump would be ok .... and when the IDE finishes instrumentation it crashes the jvm =( This is really annoying .... if I can somehow help to diagnose/resolve the issue - I would be glad o help out.
There is no instrumentation needed to do the heap dump. Are you using "Profile-> Take Heap Dump" to take a heap dump?
Yes, exactly, but for some reason NB starts instrumenting the classes at that same time
Are you still able to reproduce it in the latest dev builds? In case you can successfully reproduce the problem we would need the complete message.log to see what is happening.
Target milestone cleanup.
Milestone cleanup: future->next
Nothing happened with this issue for more than a year -> closing as invalid. Were it problem with jdk, it should not happen any more (there were 3 new versions of both jdk 1.5 and 1.6).