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.
Created attachment 158117 [details] jvm-cpu-usage Something strange is happening in Dev build of NB - it endlessly attaches to target Java process of my application, thus making it impossible to debug running application. There are following peculiarities: - Java process is Apache Karaf (http://karaf.apache.org/) with set of our custom modules deployed - NB successfully attaches to that process at some early stage of startup .. - .. but after process is completely started, attaching to target process never ends - target process consumes 25-30% of 4-core CPU, NB CPU usage is close to zero, but it is "somewhat laggy" - once per few seconds it reacts on user actions with significant delay. - problem is not reproducible with plain karaf (i.e. without custom budnles) - problem is reproducible with Dev Builds of NetBeans (recent: 20160112, ancient: 20151215) - problem is NOT reproducible with NB Release 8.1 - problem is reproducible in both x32 and x64 target JVMs (1.8.0_66) - i've tried to check what is happening be opening target process in VisualVM in parallel to Netbeans - updates in VisualVM hanged until i've stopped Netbeans (VisualVM does not hang when attaching from NB Release 8.1) - I've checked native threads via ProcessExplorer (https://technet.microsoft.com/en-us/sysinternals/processexplorer.aspx). It shows around 7-8 threads (out of total 230 threads) are constantly busy all the time with CPU usage of 1%..7% each. I've captured stacks at various times - few variations i've noticed are provided below. Notes: ~ there are around 230 threads in total in Karaf - that is normal. ~ JVM_ResolveClass frequently appears when debugger is not attaching - therefore should be treated as normal case - Is there are something else i can do to diagnose the problem? ntoskrnl.exe!KeSetEvent+0x6ca ntoskrnl.exe!KeWaitForMultipleObjects+0xd52 ntoskrnl.exe!KeWaitForSingleObject+0x19f ntoskrnl.exe!PoStartNextPowerIrp+0xbb4 ntoskrnl.exe!PoStartNextPowerIrp+0x1841 ntoskrnl.exe!KeWaitForMultipleObjects+0xf5d ntoskrnl.exe!KeWaitForSingleObject+0x19f ntoskrnl.exe!NtWaitForSingleObject+0xde ntoskrnl.exe!KeSynchronizeExecution+0x3a23 ntdll.dll!NtWaitForSingleObject+0xa KERNELBASE.dll!WaitForSingleObjectEx+0x9c jvm.dll!JVM_FindSignal+0x2d6d jvm.dll!JVM_GetThreadStateNames+0x21c9c jvm.dll!JVM_GetThreadStateNames+0x223b2 jvm.dll!JVM_GetThreadStateNames+0xb6f5 jdwp.dll!Agent_OnLoad+0x12caf jdwp.dll!Agent_OnLoad+0x3e34 jdwp.dll!Agent_OnLoad+0x56da jvm.dll!JVM_GetThreadStateNames+0x19968 jvm.dll!JVM_GetManagementExt+0x93bda ntoskrnl.exe!KeSetEvent+0x6ca ntoskrnl.exe!KeWaitForMultipleObjects+0xd52 ntoskrnl.exe!KeWaitForSingleObject+0x19f ntoskrnl.exe!PoStartNextPowerIrp+0xbb4 ntoskrnl.exe!PoStartNextPowerIrp+0x1841 ntoskrnl.exe!PoStartNextPowerIrp+0x1ab7 jvm.dll+0x810f jvm.dll!JNI_GetCreatedJavaVMs+0x193b jdwp.dll!Agent_OnLoad+0xe8a9 jdwp.dll!Agent_OnLoad+0x1cbf jdwp.dll!Agent_OnLoad+0x3e9d jdwp.dll!Agent_OnLoad+0x56da jvm.dll!JVM_GetThreadStateNames+0x19968 jvm.dll!JVM_GetManagementExt+0x93bda ntoskrnl.exe!KeSetEvent+0x6ca ntoskrnl.exe!KeWaitForMultipleObjects+0xd52 ntoskrnl.exe!KeWaitForSingleObject+0x19f ntoskrnl.exe!PoStartNextPowerIrp+0xbb4 ntoskrnl.exe!PoStartNextPowerIrp+0x1841 ntoskrnl.exe!KeWaitForMultipleObjects+0xf5d ntoskrnl.exe!KeWaitForSingleObject+0x19f ntoskrnl.exe!NtWaitForSingleObject+0xde ntoskrnl.exe!KeSynchronizeExecution+0x3a23 ntdll.dll!NtWaitForSingleObject+0xa KERNELBASE.dll!WaitForSingleObjectEx+0x9c jvm.dll!JVM_FindSignal+0x2c9a jvm.dll!JVM_ResolveClass+0x36d77 jvm.dll!JVM_ResolveClass+0x56ab7 jvm.dll!JVM_MonitorWait+0xfe jvm.dll!JVM_ResolveClass+0x56e9a
This is a very specific problem, likely out of Java control. There is probably some interference in some native services, which makes it hard to diagnose. I'm not aware of any changes in NetBeans dev builds that could cause such behavior. Are you sure that you're running both NetBeans 8.1 and NetBeans dev on the same JDK? NetBeans dev builds run with different command-line options than release builds. They have e.g. assertions on, etc. Can you please copy netbeans_default_options from netbeans.conf of 8.1 to netbeans.conf of the dev build and try that? Since, as you say, the bug is reproducible only with your custom modules deployed, we can not reproduce the bug and we could only think about steps that you could do to actually discover the issue. Are you attaching with shmem? Try dt_socket, if it makes any difference...
I've already moved to another project and therefore did not come across this use-case for a long time. Just got chance to recheck status with current latest versions of everything on the target project (whose components were massively changed over time) and it appears that problem does not appear ... so, I think it has sense to close this issue until me or someone else will be able to reproduce it once again.