Please use the Apache issue tracking system for new NetBeans issues (https://issues.apache.org/jira/projects/NETBEANS0/issues) !!
Bug 174668 - [68cat] Debugging while Scanning - Projects
[68cat] Debugging while Scanning - Projects
Status: RESOLVED INCOMPLETE
Product: editor
Classification: Unclassified
Component: Parsing & Indexing
6.x
PC Windows XP
: P2 (vote)
: 6.x
Assigned To: Vitezslav Stejskal
issues@editor
indexing
:
: 174742 (view as bug list)
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2009-10-15 15:33 UTC by stefan79
Modified: 2010-04-07 10:39 UTC (History)
7 users (show)

See Also:
Issue Type: DEFECT
:


Attachments
Snapshot while waiting at the if-Statement (445.79 KB, application/octet-stream)
2009-10-15 15:36 UTC, stefan79
Details
Snapshot taken after debugger stuck for several minutes (23.30 KB, application/octet-stream)
2009-10-19 17:20 UTC, neilg
Details
log file requested (294.45 KB, text/plain)
2009-10-28 20:35 UTC, gholmer
Details
log file as requested (299.06 KB, text/plain)
2009-12-09 08:02 UTC, gholmer
Details
profiler dump (48.46 KB, application/octet-stream)
2010-03-24 19:48 UTC, gholmer
Details
NetBeans log file (.netbeans/dev/var/log/messages.log) (58.32 KB, text/x-log)
2010-03-24 19:50 UTC, gholmer
Details
another profiler snapshot (87.37 KB, application/octet-stream)
2010-03-24 20:10 UTC, gholmer
Details
log file at the time of above snapshot (76.27 KB, text/plain)
2010-03-24 20:10 UTC, gholmer
Details

Note You need to log in before you can comment on or make changes to this bug.
Description stefan79 2009-10-15 15:33:04 UTC
[ 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.
Comment 1 stefan79 2009-10-15 15:36:17 UTC
Created attachment 89553 [details]
Snapshot while waiting at the if-Statement
Comment 2 Martin Entlicher 2009-10-16 11:31:37 UTC
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...
Comment 3 Martin Entlicher 2009-10-16 14:54:33 UTC
*** Issue 174742 has been marked as a duplicate of this issue. ***
Comment 4 neilg 2009-10-19 17:20:15 UTC
Created attachment 89700 [details]
Snapshot taken after debugger stuck for several minutes
Comment 5 neilg 2009-10-19 17:24:56 UTC
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.
Comment 6 Martin Entlicher 2009-10-21 17:00:23 UTC
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?
Comment 7 stefan79 2009-10-21 17:16:58 UTC
I´ve a "Java Application" - Project.
Comment 8 stefan79 2009-10-21 19:27:41 UTC
It´s not always, but often.
And after that, debugging is a probleme.
Comment 9 Martin Entlicher 2009-10-22 14:16:09 UTC
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.
Comment 10 gholmer 2009-10-28 20:35:05 UTC
Created attachment 90189 [details]
log file requested
Comment 11 Martin Entlicher 2009-10-29 08:55:18 UTC
Thanks Glenn. From the log it's apparent that the re-parsing is triggered by focus gain/focus lost events.
Comment 12 Martin Entlicher 2009-10-29 08:56:48 UTC
There's no "parsing" sub-component, so I'm passing this to "source".
Comment 13 Vitezslav Stejskal 2009-11-02 09:06:38 UTC
"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
Comment 14 gholmer 2009-12-09 08:01:11 UTC
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
Comment 15 gholmer 2009-12-09 08:02:08 UTC
Created attachment 92340 [details]
log file as requested
Comment 16 Vitezslav Stejskal 2009-12-10 07:08:12 UTC
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
Comment 17 gholmer 2010-03-22 16:01:13 UTC
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.
Comment 18 Michel Graciano 2010-03-22 16:10:34 UTC
(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.
Comment 19 gholmer 2010-03-24 19:47:50 UTC
Attaching a profiler dump and messages.log taken while debugger was unresponsive.
Comment 20 gholmer 2010-03-24 19:48:34 UTC
Created attachment 95721 [details]
profiler dump
Comment 21 gholmer 2010-03-24 19:50:23 UTC
Created attachment 95723 [details]
NetBeans log file (.netbeans/dev/var/log/messages.log)

These two attachments were with the 201003230200 build.
Comment 22 gholmer 2010-03-24 20:10:01 UTC
Created attachment 95724 [details]
another profiler snapshot
Comment 23 gholmer 2010-03-24 20:10:44 UTC
Created attachment 95725 [details]
log file at the time of above snapshot
Comment 24 Vitezslav Stejskal 2010-03-25 12:24:00 UTC
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.
Comment 25 gholmer 2010-03-25 13:56:54 UTC
The machine is definitely not overloaded. As it happens, I just got a new machine two days ago (Intel Core2 Duo @3GHz, 4G memory).
Comment 26 jjschum 2010-03-25 15:21:41 UTC
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.
Comment 27 Jiri Kovalsky 2010-03-30 13:37:54 UTC
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!
Comment 28 Tomas Pavek 2010-03-30 16:34:43 UTC
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.
Comment 29 gholmer 2010-04-06 11:52:48 UTC
It's been suggested that 182064 more correctly describes the issue; I've added another profiler snapshot there.
Comment 30 Vitezslav Stejskal 2010-04-07 10:39:31 UTC
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


By use of this website, you agree to the NetBeans Policies and Terms of Use. © 2014, Oracle Corporation and/or its affiliates. Sponsored by Oracle logo