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.
Build: NetBeans IDE 7.4 (Build 201310111528) VM: Java HotSpot(TM) 64-Bit Server VM, 23.7-b01, Java(TM) SE Runtime Environment, 1.7.0_17-b02 OS: Windows 7 User Comments: GUEST: Just left the IDE open over night. Started happening with the upgrade to 7.4 patch 2. It has happened every night since then. I have various Java and JSP source files open. I'm running with 2GB of memory in the VM. It normally uses 500-800MB of memory when working with our project, but goes to max if I leave it running. GUEST: Just leave IDE running, doing nothing, overnight. Doesn't happen all the time, but pretty frequently. GUEST: Used GlassFish with one application deployed. Did a lot of deploy and undeploy and left the computer for about 90 minutes. When coming back the error occurred. jarome: This happened over night, when I was doing nothing with the open NetBeans. No programs were running from it. vsigler: The IDE got stuck at the background scanning process after SVN update. Note that there were about 12 maven projects open at the time. devon_c_miller: I left the ide open overnight. Nothing should have been happening. GUEST: Not sure it matters, but left Tomcat running with a web application running over the weekend. Stacktrace: java.lang.OutOfMemoryError: Java heap space at java.util.HashMap.resize(HashMap.java:559) at java.util.HashMap.addEntry(HashMap.java:851) at java.util.HashMap.put(HashMap.java:484) at com.sun.tools.jdi.TargetVM.send(TargetVM.java:283) at com.sun.tools.jdi.VirtualMachineImpl.sendToTarget(VirtualMachineImpl.java:1032) at com.sun.tools.jdi.PacketStream.send(PacketStream.java:59)
Created attachment 146753 [details] stacktrace
analyzed reports #721397 - The IDE got stuck at the background scanning process after SVN update. Note that there were about 12 maven projects open at the time. may be related to a lot of subversion-related files: Q:\sources\ibp-conf\target\test-classes\*. Make sure Q:\sources\ibp-conf\target is svn-ignored (does not look that way). Also please switch to svnkit instead of keeping CLI as your svn client. BTW svn cache was improved in 8.0 so the amount of memory used for svn should be improved in 8.0 #707825 - Just leave IDE running, doing nothing, overnight. Doesn't happen all the time, but pretty frequently. mega large hashmap with over 3 mil. entries: Local Variable: java.util.HashMap#39832 - each entry as <String, Packet> in t com.sun.tools.jdi.TargetVM.send(TargetVM.java:283) Local Variable: com.sun.tools.jdi.Packet#601491 Local Variable: com.sun.tools.jdi.TargetVM#10 Local Variable: java.util.HashMap#39832 at com.sun.tools.jdi.VirtualMachineImpl.sendToTarget(VirtualMachineImpl.java:1032) at com.sun.tools.jdi.PacketStream.send(PacketStream.java:59) at com.sun.tools.jdi.JDWP$ThreadReference$Status.enqueueCommand(JDWP.java:5086) Local Variable: com.sun.tools.jdi.PacketStream#1 at com.sun.tools.jdi.JDWP$ThreadReference$Status.process(JDWP.java:5072) Local Variable: com.sun.tools.jdi.VirtualMachineImpl#10 at com.sun.tools.jdi.ThreadReferenceImpl.jdwpStatus(ThreadReferenceImpl.java:271) Local Variable: com.sun.tools.jdi.ThreadReferenceImpl$LocalCache#112 at com.sun.tools.jdi.ThreadReferenceImpl.status(ThreadReferenceImpl.java:284) at org.netbeans.modules.debugger.jpda.jdi.ThreadReferenceWrapper.status(ThreadReferenceWrapper.java:1067) as it is in com.sun.* classes i doubt we can do anything, but i have no idea how jdi works so leaving this to martin.
In report #730826 there is a HashMap with retained size 607,287,703 bytes. It's accessed at java.util.HashMap.put(HashMap.java:484) at com.sun.tools.jdi.TargetVM.send(TargetVM.java:283) Local Variable: com.sun.tools.jdi.TargetVM#35 Local Variable: java.util.HashMap#61366 Local Variable: com.sun.tools.jdi.Packet#262573 at com.sun.tools.jdi.VirtualMachineImpl.sendToTarget(VirtualMachineImpl.java:1032) at com.sun.tools.jdi.PacketStream.send(PacketStream.java:59) at com.sun.tools.jdi.JDWP$ThreadReference$Status.enqueueCommand(JDWP.java:5086) at com.sun.tools.jdi.JDWP$ThreadReference$Status.process(JDWP.java:5072) at com.sun.tools.jdi.ThreadReferenceImpl.jdwpStatus(ThreadReferenceImpl.java:271) at com.sun.tools.jdi.ThreadReferenceImpl.status(ThreadReferenceImpl.java:284) But there are missing "JDI Target VM Interface" and "JDI Internal Event Handler" threads. This is why the data are never cleared. I do not see any exception in the associated log file, that would indicate breaking these threads. On the other hand, there are 44 (!) threads named "DisconnectableInputStream source reader". This looks like a defect in JDI, but without steps to reproduce, this will likely end up as will-not-fix.
*** Bug 246858 has been marked as a duplicate of this bug. ***
*** Bug 249558 has been marked as a duplicate of this bug. ***
According to https://netbeans.org/bugzilla/show_bug.cgi?id=249558#c4 the remote VM was disconnected already, but JDI is still trying to send the packets. We should halt debugging when we get VMDisconnectedException.
Hopefully fixed by changeset: 282701:4ab7e9ef4552 http://hg.netbeans.org/core-main/rev/4ab7e9ef4552
Integrated into 'main-silver', will be available in build *201501060001* on http://bits.netbeans.org/dev/nightly/ (upload may still be in progress) Changeset: http://hg.netbeans.org/main-silver/rev/4ab7e9ef4552 User: mentlicher@netbeans.org Log: #243837: Dispose the VM when VMDisconnectedException is thrown.
*** Bug 250635 has been marked as a duplicate of this bug. ***