It doesn't take much, it seems, to get the Netbeans IDE to lock up hard. It doesn't use any CPU while it's frozen. It's just locked up. And it never unfreezes on its own. I always have to force kill it. What's worse, since there's no autosave feature, I keep losing work, despite the fact that I've developed a habit of saving frequently due to this problem. I'm using Netbeans on Mac OS X Lion. Note that the hangs occur always when I'm either just typing or doing something to text, like reindenting. Whenever I force kill it, I get a crash dump produced by the OS. I'm going to upload several of them.
Created attachment 110480 [details] hang log
Created attachment 110481 [details] hang log
Created attachment 110482 [details] hang log
Created attachment 110483 [details] spin log
Created attachment 110484 [details] hang log
NetBeans locked up again today so I tried getting a thread dump according to this web page: http://wiki.netbeans.org/GenerateThreadDump However, pressing Ctrl-\ has no effect, nor does "kill -QUIT". No thread dump is emitted. These appear to be the two relevant processes running: 502 14999 491 0 11:25AM ttys001 0:00.06 /bin/bash ./../platform/lib/nbexec --userdir /Users/millerti/.netbeans/7.0 --jdkhome -J-Dcom.apple.mrj.application.apple.menu.about.name=NetBeans -J-Xdock:name=NetBeans -J-Xdock:icon=./../nb/netbeans.icns --branding nb --clusters /Applications/NetBeans/NetBeans 7.0.1.app/Contents/Resources/NetBeans/nb:./../ergonomics:/Applications/NetBeans/NetBeans 7.0.1.app/Contents/Resources/NetBeans/ide:/Applications/NetBeans/NetBeans 7.0.1.app/Contents/Resources/NetBeans/java:./../xml:/Applications/NetBeans/NetBeans 7.0.1.app/Contents/Resources/NetBeans/apisupport:./../webcommon:/Applications/NetBeans/NetBeans 7.0.1.app/Contents/Resources/NetBeans/websvccommon:./../enterprise:./../mobility:/Applications/NetBeans/NetBeans 7.0.1.app/Contents/Resources/NetBeans/profiler:/Applications/NetBeans/NetBeans 7.0.1.app/Contents/Resources/NetBeans/ruby:./../python:./../php:./../visualweb:./../soa:./../identity:./../uml:/Applications/NetBeans/NetBeans 7.0.1.app/Contents/Resources/NetBeans/harness:./../cnd:./../dlight:./../groovy:./../extra:./../javafx:./../javacard: -J-Dnetbeans.importclass=org.netbeans.upgrade.AutoUpgrade -J-Dnetbeans.accept_license_class=org.netbeans.license.AcceptLicense -J-XX:MaxPermSize=384m -J-Xmx768m -J-client -J-Xss2m -J-Xms32m -J-XX:PermSize=32m -J-Dapple.laf.useScreenMenuBar=true -J-Dapple.awt.graphics.UseQuartz=true -J-Dsun.java2d.noddraw=true 502 15219 14999 0 11:25AM ttys001 10:01.39 /System/Library/Java/JavaVirtualMachines/1.6.0.jdk/Contents/Home/bin/java -Djdk.home=/System/Library/Java/JavaVirtualMachines/1.6.0.jdk/Contents/Home -classpath /Applications/NetBeans/NetBeans 7.0.1.app/Contents/Resources/NetBeans/platform/lib/boot.jar:/Applications/NetBeans/NetBeans 7.0.1.app/Contents/Resources/NetBeans/platform/lib/org-openide-modules.jar:/Applications/NetBeans/NetBeans 7.0.1.app/Contents/Resources/NetBeans/platform/lib/org-openide-util-lookup.jar:/Applications/NetBeans/NetBeans 7.0.1.app/Contents/Resources/NetBeans/platform/lib/org-openide-util.jar:/Applications/NetBeans/NetBeans 7.0.1.app/Contents/Resources/NetBeans/platform/lib/locale/boot_ja.jar:/Applications/NetBeans/NetBeans 7.0.1.app/Contents/Resources/NetBeans/platform/lib/locale/boot_pt_BR.jar:/Applications/NetBeans/NetBeans 7.0.1.app/Contents/Resources/NetBeans/platform/lib/locale/boot_ru.jar:/Applications/NetBeans/NetBeans 7.0.1.app/Contents/Resources/NetBeans/platform/lib/locale/boot_zh_CN.jar:/Applications/NetBeans/NetBeans 7.0.1.app/Contents/Resources/NetBeans/platform/lib/locale/org-openide-modules_ja.jar:/Applications/NetBeans/NetBeans 7.0.1.app/Contents/Resources/NetBeans/platform/lib/locale/org-openide-modules_pt_BR.jar:/Applications/NetBeans/NetBeans 7.0.1.app/Contents/Resources/NetBeans/platform/lib/locale/org-openide-modules_ru.jar:/Applications/NetBeans/NetBeans 7.0.1.app/Contents/Resources/NetBeans/platform/lib/locale/org-openide-modules_zh_CN.jar:/Applications/NetBeans/NetBeans 7.0.1.app/Contents/Resources/NetBeans/platform/lib/locale/org-openide-util-lookup_ja.jar:/Applications/NetBeans/NetBeans 7.0.1.app/Contents/Resources/NetBeans/platform/lib/locale/org-openide-util-lookup_pt_BR.jar:/Applications/NetBeans/NetBeans 7.0.1.app/Contents/Resources/NetBeans/platform/lib/locale/org-openide-util-lookup_ru.jar:/Applications/NetBeans/NetBeans 7.0.1.app/Contents/Resources/NetBeans/platform/lib/locale/org-openide-util-lookup_zh_CN.jar:/Applications/NetBeans/NetBeans 7.0.1.app/Contents/Resources/NetBeans/platform/lib/locale/org-openide-util_ja.jar:/Applications/NetBeans/NetBeans 7.0.1.app/Contents/Resources/NetBeans/platform/lib/locale/org-openide-util_pt_BR.jar:/Applications/NetBeans/NetBeans 7.0.1.app/Contents/Resources/NetBeans/platform/lib/locale/org-openide-util_ru.jar:/Applications/NetBeans/NetBeans 7.0.1.app/Contents/Resources/NetBeans/platform/lib/locale/org-openide-util_zh_CN.jar:/System/Library/Java/JavaVirtualMachines/1.6.0.jdk/Contents/Home/lib/dt.jar -Dnetbeans.system_http_proxy=DIRECT -Dnetbeans.system_http_non_proxy_hosts= -Dnetbeans.dirs=/Applications/NetBeans/NetBeans 7.0.1.app/Contents/Resources/NetBeans/nb:./../ergonomics:/Applications/NetBeans/NetBeans 7.0.1.app/Contents/Resources/NetBeans/ide:/Applications/NetBeans/NetBeans 7.0.1.app/Contents/Resources/NetBeans/java:./../xml:/Applications/NetBeans/NetBeans 7.0.1.app/Contents/Resources/NetBeans/apisupport:./../webcommon:/Applications/NetBeans/NetBeans 7.0.1.app/Contents/Resources/NetBeans/websvccommon:./../enterprise:./../mobility:/Applications/NetBeans/NetBeans 7.0.1.app/Contents/Resources/NetBeans/profiler:/Applications/NetBeans/NetBeans 7.0.1.app/Contents/Resources/NetBeans/ruby:./../python:./../php:./../visualweb:./../soa:./../identity:./../uml:/Applications/NetBeans/NetBeans 7.0.1.app/Contents/Resources/NetBeans/harness:./../cnd:./../dlight:./../groovy:./../extra:./../javafx:./../javacard: -Dnetbeans.home=/Applications/NetBeans/NetBeans 7.0.1.app/Contents/Resources/NetBeans/platform -Dcom.apple.mrj.application.apple.menu.about.name=NetBeans -Xdock:name=NetBeans -Xdock:icon=./../nb/netbeans.icns -Dnetbeans.importclass=org.netbeans.upgrade.AutoUpgrade -Dnetbeans.accept_license_class=org.netbeans.license.AcceptLicense -XX:MaxPermSize=384m -Xmx768m -client -Xss2m -Xms32m -XX:PermSize=32m -Dapple.laf.useScreenMenuBar=true -Dapple.awt.graphics.UseQuartz=true -Dsun.java2d.noddraw=true -XX:+HeapDumpOnOutOfMemoryError -XX:HeapDumpPath=/Users/millerti/.netbeans/7.0/var/log/heapdump.hprof org.netbeans.Main --userdir /Users/millerti/.netbeans/7.0 --branding nb Next, I tried Ctrl-C. That killed process 14999, but process 15219 still exists. Process 15219 doesn't respond to any signals at all. I attached gdb and typed "where", and this is what I got: #0 0x00007fff83b8c67a in mach_msg_trap () #1 0x00007fff83b8bdda in mach_msg () #2 0x000000010e517e6f in jio_snprintf () #3 0x000000010e517d2f in jio_snprintf () #4 0x000000010e517c8e in jio_snprintf () #5 0x000000010e516b1d in jio_snprintf () #6 0x000000010e516a5f in jio_snprintf () #7 0x000000010e6ba459 in JVM_GetClassInterfaces () #8 0x000000010e6ba1e0 in JVM_GetClassInterfaces () #9 0x000000010e5804e4 in JVM_Lseek () #10 0x000000010e6a5dbc in JNI_GetCreatedJavaVMs_Impl () #11 0x000000010ee52d36 in JNFCallStaticVoidMethod () #12 0x000000011d03d411 in setBusy () #13 0x00007fff88f14647 in __CFRUNLOOP_IS_CALLING_OUT_TO_AN_OBSERVER_CALLBACK_FUNCTION__ () #14 0x00007fff88f145a6 in __CFRunLoopDoObservers () #15 0x00007fff88ee9a6c in __CFRunLoopRun () #16 0x00007fff88ee9216 in CFRunLoopRunSpecific () #17 0x00007fff869714ff in RunCurrentEventLoopInMode () #18 0x00007fff86978c21 in ReceiveNextEventCommon () #19 0x00007fff86978aae in BlockUntilNextEventMatchingListInMode () #20 0x00007fff881ab191 in _DPSNextEvent () #21 0x00007fff881aaa95 in -[NSApplication nextEventMatchingMask:untilDate:inMode:dequeue:] () #22 0x000000011d091f6d in -[NSApplicationAWT nextEventMatchingMask:untilDate:inMode:dequeue:] () #23 0x00007fff881a73d6 in -[NSApplication run] () #24 0x000000011d03d1f0 in +[AWTStarter startAWT:] () #25 0x000000011d03cb6a in -[CPerformer perform] () #26 0x00007fff88f4411d in -[NSObject performSelector:withObject:] () #27 0x00007fff8a102830 in __NSThreadPerformPerform () #28 0x00007fff88ec3241 in __CFRUNLOOP_IS_CALLING_OUT_TO_A_SOURCE0_PERFORM_FUNCTION__ () #29 0x00007fff88ec2aad in __CFRunLoopDoSources0 () #30 0x00007fff88ee98d9 in __CFRunLoopRun () #31 0x00007fff88ee9216 in CFRunLoopRunSpecific () #32 0x000000010e46d842 in ?? () #33 0x000000010e46d299 in ?? () #34 0x000000010e46aa90 in ?? ()
One really reliable way to get NetBeans to lock up is to type something in the editor then Alt-Tab away. Someone in IRC complained that the IDE gets slow when he does that because it's scanning for source files that have been modified outside of the IDE. In my case, perhaps this is one cause of lockups. It always does lockup while I've been editing something. It NEVER locks up if all my files are saved.
Indeed, turning off "Enable auto-scanning of sources" seems to have alleviated the easily reproducible problem (so far).
Nope. Scratch that. I just had to alt-tab back and forth a couple of times, and it still locks up. This is amazingly unusable.
Please try one more time to capture thread dump. Without it we cannot analyze where is the problem Thanks PS. you can try: http://www.adaptj.com/root/webstart/stacktrace/app/launch.jnlp
I wish you'd told me about that yesterday. This morning, I started using the nightly (7.1), and so far, none of the things I did with 7.0.1 will cause 7.1 to lock up. I have had several partial crashes (unhandled exceptions), but the whole IDE didn't go down, and nothing bad happened, and I let it file the automatic bug reports. Just now, I tried starting up 7.0.1, attaching the program you gave me, and opening a snapshot of my project from when I was getting hangs. Unfortunately, I cannot easily reproduce the hang now. Honestly don't know what's different besides the pathname to my project and the fact that there's another program attached to the JVM. The best I can do now is keep using 7.1 and see if I ever get a hang. Also, if NetBeans has moved some tasks from the main or event threads to background threads, you may want to add watchdog timers for those to see if any of them hang. Lastly, that program you linked to downloads an app every time I run it. Can you tell me where it installs that app? I can't find it. Thanks.
I got the nightly to lock up. I tried this StackTrace tool, but I get this error: There is no valid license. I googled that, of course. The suggestions were to clear Java and browser caches, which I did, to no avail. I'm concerned that this tool is no longer being supported. Back in 2008, they said that the license expires every month, but we're in the middle of a month right now. I'm reopening this bug so I can get another suggestion on how to get thread dumps. So far, I have no way to generate a thread dump on a Mac.
You can use jstack utility from the JDK installation for making thread dumps.
Hello, please try the jvisualvm command, try to find the affected process in the GUI and invoke a thread dump on it. Without the thread dump we cannot do anything. I am sorry but I am for now closing the report as "incomplete". After adding the thread dump please reopen. Thanks, David
I got the same situation when using netbeans 7.0.1. I change to use 7.1 beta, that bug still remains. I try to use jvisualvm to dump, but where netbeans hang there, the jvisualvm also stopped, and after a while it crashed. I also try to use jstack to dump, where netbeans's status is normal, I can dump. But when it hang there, the jstack command also hang there. Later i will attach some snapshots , command logs, and Mac activity monitor thread dump.
Created attachment 111635 [details] netbeans snapshot when dead
Created attachment 111636 [details] activity-monitor-snap when netbeans dead
Created attachment 111637 [details] jvisualvm-snap when netbeans dead
Created attachment 111638 [details] activity-monitor-thread-dump
Created attachment 111639 [details] jstack command log(but failed)
When editing big file, that bug is easy to reproduced. my file has over 7000 lines.
Created attachment 111640 [details] jmap -heap command
Created attachment 111641 [details] jmap -dump command logs (exception occurs)
Created attachment 111642 [details] jmap -permstat command(exception occurs)
later I used jstack command, and it told me " refuse to connect "
This bug needs to be merged with http://netbeans.org/bugzilla/show_bug.cgi?id=202044
For me, as long as I have VisualVM attached and actively monitoring, the IDE won't lock up. I've been using it for days on end with no problem. I guarantee that if I were to stop using VisualVM, the lockups would start happening again. If the act of monitoring the IDE is affecting the timing of activities in the IDE, then that would suggest that we're just avoiding race conditions. I've had this happen with lots of things, where simply logging messages to a file would prevent the problem. It's infuriating, but it's common with multithreaded workloads that don't mutex resources properly. Given the frequency at which NetBeans reports to me unhandled exceptions, I wouldn't be surprised if this were the case. The fact that it locks up so hard that we can't do a thread dump is bizarre and suggests that the data race (if that's what it is) is at a lower level. That would suggest a bug in the platform support, but something Netbeans is doing is triggering it in a way that other Java apps do not.
Well, I finally got NetBeans to lock up on me while VisualVM was monitoring it. When the lockup occurred, I asked it to generate a thread dump, but all it does is just sit there forever saying "Generating Thread Dump...". No errors or anything. Since there seems to be no way to get VisualVM to dump what it was monitoring, I'm attaching a screenshot of the table of threads that were running at the time it froze up.
Oops. See bug 202044 for the images.
This is definitely still an issue, and occurs frequently in the PHP IDE version as well. Netbeans tends to lock up when it's doing it's nifty variable highlighting in the current scope. Seems to be especially "sensitive" if the variable happens to be "$this" or some other frequently used variable as it then potentially has to highlight hundreds of occurrences in the class being edited. Any news on this ?
The reports by theosib and zn_cn_2 are almost surely a JVM bug. Such bugs are rarely workaroundable (or fixable) in NetBeans, sorry. Could you please try to update your JDK/system? I have asked two developers who have Macs and neither of them is experiencing these lockups. BTW: "jstack -F" sometimes produces a thread dump even in case the JVM itself is locked (e.g. doing GC). Not sure if the outcome is trustworthy, but might be interesting to see it. Eggie: if you problem is different from the theosib's, could you please generate a thread dump and create a new bug.
I did do a "jstack -F". Please see bug 202044, first attachment.
My JVM is up-to-date as it's going to get for a while, as Apple hands its port back over to Oracle. Since Netbeans is an Oracle project, would you mind phoning up the JVM guys and asking them to give the Mac some priority? Also, I use other Java programs, like jEdit, and I don't experience lockups. Sure, it might be a JVM bug, but all the same, Netbeans is doing something to trigger it, while others are not. Therefore, it seems like it may be something you can work around, in theory, with some kind of magic to figure out what's going on, after the JVM has mangled itself beyond recognition. Also, something that would really help this situation would be to add proper crash protection. People have been asking to have that added to Netbeans for many years.
Netbeans hangs where you can't get a thread dump are not a new phenomenon. Here's a discussion from 2006: http://netbeans-org.1045718.n5.nabble.com/freezing-on-Mac-td2880151.html Someone was experiencing this in 2010: http://lists.apple.com/archives/java-dev/2010/Apr/msg00096.html Of course, these could be completely unrelated. I googled for "netbeans (hang OR lockup OR freeze)". Not all of the hangs are on Macs.
(In reply to comment #33) > My JVM is up-to-date as it's going to get for a while, as Apple hands its port > back over to Oracle. Since Netbeans is an Oracle project, would you mind > phoning up the JVM guys and asking them to give the Mac some priority? Also, I > use other Java programs, like jEdit, and I don't experience lockups. Sure, it > might be a JVM bug, but all the same, Netbeans is doing something to trigger > it, while others are not. Therefore, it seems like it may be something you can Possibly there is some trigger, although it might be something like being big. I remember only one case where there was a successful workaround for a Mac JDK bug. It is normally very hard to figure out what is the problem, and often impossible to workaround. Suggestions where the problem might be, or what to do to workaround it are very welcome. One thing that might be worth trying is to start the IDE with the following command line option: -J-Dorg.netbeans.modules.masterfs.watcher.disable Which disables native listening on FS changes - not very probable that it would help. And, BTW, I have found info about at least one more (non-NetBeans) application that is crashing in the very same way, so its definitely not "NetBeans only". > work around, in theory, with some kind of magic to figure out what's going on, > after the JVM has mangled itself beyond recognition. > > Also, something that would really help this situation would be to add proper > crash protection. People have been asking to have that added to Netbeans for > many years. Sorry, I have no idea what you mean. Could you please add more details on what you are proposing. But when the JVM itself is crashes/locks this way, there is virtually nothing a Java code could do - the Java code is not being executed.
(In reply to comment #34) > Netbeans hangs where you can't get a thread dump are not a new phenomenon. > Here's a discussion from 2006: > > http://netbeans-org.1045718.n5.nabble.com/freezing-on-Mac-td2880151.html Yes, it sometimes (quite rarely actually) happens that the JVM locks in such a way that it does not produce a thread dump. I still do not see much that can be done from inside a Java application to prevent this, or help generate the thread dump. > > Someone was experiencing this in 2010: > > http://lists.apple.com/archives/java-dev/2010/Apr/msg00096.html > > Of course, these could be completely unrelated. I googled for "netbeans (hang > OR lockup OR freeze)". Not all of the hangs are on Macs. "netbeans (hang OR lockup OR freeze)" will most likely lead to a lot of cases where NetBeans itself deadlocks (i.e. there is a Java code level deadlock), which are being regularly fixed. This definitely seems like a problem in the native JVM code itself, which is different (rarer).
Correction, the cmd line option should be: -J-Dorg.netbeans.modules.masterfs.watcher.disable=true
> > Also, something that would really help this situation would be to add proper > > crash protection. People have been asking to have that added to Netbeans for > > many years. > > Sorry, I have no idea what you mean. Could you please add more details on what > you are proposing. But when the JVM itself is crashes/locks this way, there is > virtually nothing a Java code could do - the Java code is not being executed. I feel like you're pulling my leg, but just in case you're not: It is common for productivity applications to protect the user against data loss due to crashes and hangs. They do this by taking periodic snapshots of edited documents or keeping a log of unsaved edits. If the application does crash or terminate abnormally, when it is restarted, it will see snapshot and restore the user to the last snapshot. Not all changes are necessarily saved, but this tends to minimize dataloss. Off the top of my head, I can think of quite a number of systems that implement some form of crash recovery: Microsoft Office iWork OpenOffice/LibreOffice Eclipse (NetBeans' main competitor) Firefox Safari Google Chrome Journaled file systems (e.g. ext3, HFS+, NTFS) Databases (e.g. Oracle) Many years ago, it was requested that NetBeans implement crash recovery, but so far, no one has seen fit to implement it. Does that answer your question?
Why is this marked as resolved? In PHP IDE if I do subsequent indents 1 row after another too quickly it locks the entire IDE for it to never recover. I did not have these issues until upgrading to 7.1. This unfortunately has cost me HOURS of work and subsequently hundreds of dollars in time. It's unfortunate the IDE has zero dataloss recovery (it restarts with my progress at the same location I was at more then 5 hours ago!) and crashes so easily (was PHP even tested?). At this point will be considering a new IDE, what a shame.
I may have found a work around for this problem. In the least it is something you can try. I develop primarily java ee applications and since I started using netbeans on Mac I have had problems with it constantly crashing while editing large EJB/POJ/XML/JSP files. To alleviate the problem I've tried everything: turning off various options like code folding etc, uninstalling all plugins.. nothing seemed to work. I came to the conclusion it must be a bug in the Mac JVM implementation. My solution was to run netbeans in the 32-bit version of the JVM. To do this you add the '-J-d32' flag to JVM options in <netbeans_install_dir>/NetBeans 7.1.app/Contents/Resources/NetBeans/etc/netbeans.conf
