Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
[jdt-dev] Debugging unbearably slow in specific situation?

Hi,

Let me check if this is worth a bugzilla: Is anybody else
seeing the following?

In a debug session
(1) debugger had previously stop at various breakpoints
(2) then control flow enters JrtFileSystem.walkModuleImage()

at this point it's practically impossible to debug beyond this
method invocation, because stepping takes "forever" (deep inside
internals of file walking).
Sometimes I can do individual step overs, but I am unable to
reach the bottom of walkModuleImage().

I've seen this and & off for quite a while, always at this same
code location.

Right now, pressing suspend opens the call stack, but keeps
saying "Stepping" and step buttons remain disabled. Only
"Resume" and "Terminate" are enabled.

I see no sign of any locks being involved. All other threads
are basically idle. I already said "Skip All Breakpoints".
After "Resume" for all threads and letting it sit a minute,
I *may* be lucky to be able to continue stepping, but after a
few F7's it may get stuck again.

What's funny: the same debugging works fine, if no breakpoint was
hit before walkModuleImage().

I'd file a bug against JDT/Debug, but frankly I have no clue
if this is fixable in JDT, or a problem of the JVM, or just
a conspiracy against me, that happens only on my machine ;p

I recall that some years ago I had a similar problem, when
the program I was debugging launched Ant in-process. I think
back then it got stuck during XML parsing. Not sure if there's
any relation.

anyone?
Stephan


Back to the top