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 # : 200910140201 ] [ JDK VERSION : 1.6.* ] I´ve often the situation that I start a Java-Debug-Session and then while step-by-step - debugging, the scanning-projects starts. After that the IDE waits and waits .. I´ll attach a snapshot where I was waiting some Minutes, to step over a very simple if. The If-Statement is: if (!myBooleanVariable) {... //Debugger stands here. Maybe It´s the same as descripted at 174659.
Created attachment 89553 [details] Snapshot while waiting at the if-Statement
This looks different from issue #174659. Most of the time is taken in Parsing & Indexing Loop. We had such problem in the past (that debugger triggered re-parsing of the source files), but it was already fixed. This suggests that the issue re-appears again. I'll try to find the original issue we had...
*** Issue 174742 has been marked as a duplicate of this issue. ***
Created attachment 89700 [details] Snapshot taken after debugger stuck for several minutes
The snapshot just added (StuckDebugger.nps) was taken after the debugger hung for around four minutes. It has now been stuck for > 10 minutes. Debugging is unusable.
I can not reproduce start of scanning during stepping in debugger. Neither on a simple JavaSE project, nor when debugging NetBeans. What kind of project do you debug? Does the re-scan appear always during stepping? The second snapshot StuckDebugger.nps looks more like issue #174849 to me. Can you please check the behavior after the fix of that issue gets to the NetBeans build?
I´ve a "Java Application" - Project.
It´s not always, but often. And after that, debugging is a probleme.
Can you please add this option to etc/netbeans.conf: -J-Dorg.netbeans.modules.parsing.impl.indexing.RepositoryUpdater.level=FINE And attach the messages.log file here after it happens several times? This option will log what triggered re-parsing of sources, which should help to identify the problem. Thanks.
Created attachment 90189 [details] log file requested
Thanks Glenn. From the log it's apparent that the re-parsing is triggered by focus gain/focus lost events.
There's no "parsing" sub-component, so I'm passing this to "source".
"From the log it's apparent that the re-parsing is triggered by focus gain/focus lost events." - Not to me. Glenn, what sort of log file is this? I can see that the initial scan was started and well in progress with scanning your sources, then there was some editor ativity (opening/closing files perhaps or maybe just switching tabs) and then it ends. Did you kill the IDE? When did you start debugging? Could you please start the IDE, let it scan your sources and then start debugging and reproduce the problem? Thanks
It does not seem nearly as bad in RC2 (200912030751), but there are still very noticeable pauses when stepping through code, during which the continue icon in the toolbar (green arrow) flashes. I've attached another messages.log generated as follows: 1) add option requested above by Martin (RepositoryUpdater.level=FINE) 2) start IDE 3) wait for "Opening Projects" and "Scanning projects..." to complete 4) attach debugger to running GlassFish process 5) set breakpoint and single-step through code when breakpoint is hit 6) stop NetBeans and save log file
Created attachment 92340 [details] log file as requested
I'm sorry, but the log file shows nothing. There was the initial scan, after that (presumably) some editor activity and then the IDE exited. Maybe a profiler snapshot could reveal something especially if there are only short (but noticeable) pauses. Please try to use Profile Me! during the step #4 on your list. Thanks
Please explain what you mean by "Profile Me!". I am running nightly builds of 6.9 and find this problem far worse than it was in 6.8.
(In reply to comment #17) > Please explain what you mean by "Profile Me!". I am running nightly builds of > 6.9 and find this problem far worse than it was in 6.8. http://wiki.netbeans.org/FitnessViaPartnership It should answer you.
Attaching a profiler dump and messages.log taken while debugger was unresponsive.
Created attachment 95721 [details] profiler dump
Created attachment 95723 [details] NetBeans log file (.netbeans/dev/var/log/messages.log) These two attachments were with the 201003230200 build.
Created attachment 95724 [details] another profiler snapshot
Created attachment 95725 [details] log file at the time of above snapshot
I can see a lot of activity in the 'JDI Target VM Interface' thread, which I assume is ok during a debugging session. Besides of that there is almost no activity in other threads. So, it's hard to say what is causing the pauses. Maybe your system is just overloaded.
The machine is definitely not overloaded. As it happens, I just got a new machine two days ago (Intel Core2 Duo @3GHz, 4G memory).
Today as I was debugging, the variable tab was slow to respond. The scroll bar responded slowly, and expanding a collection was very slow. There were 24 items in the variable tab at the time. When I tried to step or continue in the debugger, it did not respond. I also noticed that Glassfish was using over 95% cpu.
Guys, can somebody take a look at this again? Glenn said that going one step in debugging session typically took several minutes and later it ended up unresponsive completely. Can we create a patched version of the affected modules that would log additional debugging information for us? Any other advice for Glenn? Thanks!
Only the first attached snapshot seems related to what this report was created for: scanning during debugging. The other snapshots added by neilg and gholmer has no sign of scanning and are likely quite different problem. So I'd suggest to close this report and file a new bug on debugger. In the new report summarize the problem and mention how long a step may take when the debugger is slow. Also point to the snapshots in this issue and please explain how they were created - e.g. how many steps in debugger happened during that. BTW it happend to me as well a few times that step over was suddenly very slow taking much CPU (while other times debugging the same code was fluent). I got very similar snapshots as Glenn - lots of time in 'JDI Target VM Interface' and in AWT thread long waits on debugger's view model. It seemed like debugger would be pulling enormous data from the target VM, though it's hard to tell from the snapshot how much the 'JDI Target VM Interface' is really doing something or just waiting.
It's been suggested that 182064 more correctly describes the issue; I've added another profiler snapshot there.
Ok, so the JDI thread related problem is tracked in issue #182064 and this report is really only about the debugger being blocked by scanning, which we have not been able to reproduce nor diagnose from the available logs/snapshots. This is why I'm closing this as INCOMPLETE. If this is still a problem and you can reproduce it with -J-Dorg.netbeans.modules.parsing.impl.indexing.RepositoryUpdater.level=FINE and/or generate the profiler snapshot, please reopen this report and attach the IDE's logfile and the snapshot. Thanks