Debugging is not a solved problem

Ever since Dave Griffith said he thought debugging was a solved problem
and that JB shouldn't work on it, I've been thinking about debugging.
I'm not very happy about it.

1. Why can't I see the value that's about to be returned? I need to
extract a variable, recompile, and wait for the next invocation
2. Why can't I see the history of a variable's values (like back in time
debugging)?
3. Why can't I track specific instances of objects after they leave scope?
4. Why can't I set IDEA to break upon entry of any method of some object
or some class?
5. Why can't I execute code when I Pause the debugger?
6. Why doesn't IDEA warn me when there's a deadlock?
7. Why can't I hotswap code in the middle of a method's execution?
8. Why doesn't IDEA provide any way for me to know if the code has
changed since the last time I started debugging / reloaded?
9. Why does IDEA jump to the beginning of the file when the JVM says
"breakpoints will be ignored for all existing invocations of the method"
after reloading?
10. Why can't I step through an expression?
11. Why can't I see a list of bean properties instead of fields for an
objeect?
12. Why does IDEA insert "x.toArray()[0]" when I select a List's first
item and click Evaluate? I obviously want to call x.get(0), so I don't
need to insert casts.
13. Why aren't final local variables used in inner classes shown
normally? Why do I need to click "this" then find "this$varname"
recursively to see all of them?
14. Why can't I step into bytecode? Disassembly is not difficult. Even
Visual Studio has done this for years.
15. Why are Watches and Frame different tabs? Why would I just want one
or the other?
16. Why does IDEA completely skip the breakpoint if it's on a line
without code? I obviously wanted to stop between the previous line of
code and the next line of code.
17. Why can't I set the breakpoint on the first line of a multiline for
loop? Couldn't IDEA be a little smarter about this?

These are just the issues I have off the top of my head with debugging.
Aren't these real problems for anyone else? For me using the debugger is
nothing short of painful, every day.

Are there any plans to revamp debugger, or at least fix some of the
annoying lower-hanging fruit in my list?

13 comments

Hello Keith,

To be honest, most of the issues better be addressed by JVM debuggee interface
team. Why not ask them?
In some cases we could indeed provide a workaround aka hack. In some other
cases we cannot go even that far.

I must agree there's still a room to improove debugging experience.
I'm just against "why doesn't IDEA handles xxx problem" mantra here.

Peace

-


Maxim Shafirov
JetBrains, Inc
http://www.jetbrains.com
"Develop with pleasure!"


0

I agree that it's problem with JVM debugger interface, but most of the
problems could be solved with editor/PSI integration and source code
instrumentation.

For example, to step through expressions, every && could be converted to
if statement. Every statement could be placed on its own line. Every
expression could have subexpressions extracted as variables. Then, line
numbers could be translated back to original source code by IDEA.

Another example, to hotswap in the middle of execution, every method
body could be surrounded by try/catch block which catches some secret
exception. When swapping changed method, VM could be paused, that
exception could be thrown in whatever methods applicable, and some local
variable (declared before the try/catch block) could be set to a
Runnable that runs the rest of the new method. The catch block runs that
Runnable.

Obviously this stuff is complicated, but I think a more effective
debugger would save me hours of time every week.

Maxim Shafirov (JetBrains) wrote:

Hello Keith,

To be honest, most of the issues better be addressed by JVM debuggee
interface team. Why not ask them?
In some cases we could indeed provide a workaround aka hack. In some
other cases we cannot go even that far.

I must agree there's still a room to improove debugging experience.
I'm just against "why doesn't IDEA handles xxx problem" mantra here.

Peace

------------------
Maxim Shafirov
JetBrains, Inc
http://www.jetbrains.com
"Develop with pleasure!"

0

Another example, to hotswap in the middle of execution, every method body

could be surrounded by try/catch block which catches some secret exception...

Keith, you can't be serious!

Again, it's waaaay to easier to fix at JVM level, including my favorite of
adding reference to method local variable from an anonymous class

-


Maxim Shafirov
JetBrains, Inc
http://www.jetbrains.com
"Develop with pleasure!"


0

I am serious about such source modification. I don't believe Sun cares
about developers. They have marked many obvious, needed enhancements and
bugs reported by me and other developers as "Won't fix" or "Not a bug."

CodeGuide has implemented many of these features so it must be possible
without modifying JVM. (Of course they have their own compiler but I
don't think it would be necessary for many of the enhancements I want.)

Maxim Shafirov (JetBrains) wrote:

>> Another example, to hotswap in the middle of execution, every method body


could be surrounded by try/catch block which catches some secret
exception...

Keith, you can't be serious!

Again, it's waaaay to easier to fix at JVM level, including my favorite
of adding reference to method local variable from an anonymous class

------------------
Maxim Shafirov
JetBrains, Inc
http://www.jetbrains.com
"Develop with pleasure!"

0

Did you ever use the Netbeans debugger?
Just try it out - there is much room for improvments.

A first step could be an improvement of the UI: Why are the objects
displayed within a tree? A table tree could do the same thing offering a
better overview...


Johannes Schneider


Maxim Shafirov (JetBrains) wrote:

Hello Keith,

To be honest, most of the issues better be addressed by JVM debuggee
interface team. Why not ask them?
In some cases we could indeed provide a workaround aka hack. In some
other cases we cannot go even that far.

I must agree there's still a room to improove debugging experience.
I'm just against "why doesn't IDEA handles xxx problem" mantra here.

Peace

------------------
Maxim Shafirov
JetBrains, Inc
http://www.jetbrains.com
"Develop with pleasure!"

0

Keith Lea wrote on 11/02/06 08:51:

Ever since Dave Griffith said he thought debugging was a solved problem
and that JB shouldn't work on it, I've been thinking about debugging.
I'm not very happy about it.


No answers, but one annoying addition:

12. Why does IDEA insert "x.toArray()[0]" when I select a List's first
item and click Evaluate? I obviously want to call x.get(0), so I don't
need to insert casts.


Why does IDEA force the evaluate window as a modal dialog? It'd be
great having this as a tab (or separate, detatchable panel) offering a
full REPL style shell (ala interactive perl / ruby).

Actually - I'd love to an interactive shell also as a specific debug-run
type - compile everything, setup the classpath, launch a shell (and
optionally run a script?)

0

Keith Lea wrote on 11/02/06 09:17:

Another example, to hotswap in the middle of execution, every method
body could be surrounded by try/catch block which catches some secret
exception. When swapping changed method, VM could be paused, that
exception could be thrown in whatever methods applicable, and some local
variable (declared before the try/catch block) could be set to a
Runnable that runs the rest of the new method. The catch block runs that
Runnable.


All sounds great, but falls down with remote debugging. 90% of the time
when I'm using the debugger its from an externally launched resin
instance/remote debugging.

0

Keith, I mean this with the greatest of respect and in the absolutely nicest of all possible ways, but if this is the best you can come up with, I'm going to stick with "Java debugging is a solved problem".

By my read, three of these are real but small usability issues, four are real but small issues that the JPDA team should look into adding to the platform debugging interface, and the rest are things so obscure that if I ever found myself wanting them it would be an indication that it was time for large scale refactoring and a serious bout of unit test creation.

It may be a difference in our workflows. I use the debugger twice per month, maximum, and only that because it is so difficult to create unit test cases for IDEA plugin functionality. All of my other bug shagging is via Ctrl-F10 in a JUnit test case.

If JetBrains had to invest more effort in dynamic application issue finding, I would suggest either adding a profiler onto IDEA or high-quality JMX integration before I recommend one more developer minute be spent on enhancing the debugger. In terms of bang-for-the-buck, there's just no competition.

--Dave Griffith

0

I agree that most of the suggestions are, err, a little over the top.

Still there are some improvements that could be made without much hacking.
For example when I try to debug my custom Swing component (another area where unit tests are difficult) Idea makes it close to impossible to find my own member variables among the
hundreds of inherited ones. Why not have an option to group members by base classes?

Also in a chained method call, Idea could easily let me choose the one to step into, rather forcing on me a series of step into, step out of.

And then my most hated debugger bug (because I do not learn to avoid it): Invoke code completion in the watches window and try to use the popup with the mouse (e.g. scrollbars) -
it just vanishes. That's so annoying.

Plus a couple of more usability fixes...

Dave Griffith wrote:

Keith, I mean this with the greatest of respect and in the absolutely nicest of all possible ways, but if this is the best you can come up with, I'm going to stick with "Java debugging is a solved problem".

By my read, three of these are real but small usability issues, four are real but small issues that the JPDA team should look into adding to the platform debugging interface, and the rest are things so obscure that if I ever found myself wanting them it would be an indication that it was time for large scale refactoring and a serious bout of unit test creation.

It may be a difference in our workflows. I use the debugger twice per month, maximum, and only that because it is so difficult to create unit test cases for IDEA plugin functionality. All of my other bug shagging is via Ctrl-F10 in a JUnit test case.

If JetBrains had to invest more effort in dynamic application issue finding, I would suggest either adding a profiler onto IDEA or high-quality JMX integration before I recommend one more developer minute be spent on enhancing the debugger. In terms of bang-for-the-buck, there's just no competition.

--Dave Griffith

0

Totally agree with Dave! Good JMX console and a profiler would be a killer!

"Dave Griffith" <dave.griffith@cnn.com> wrote in message
news:7798492.1139701155696.JavaMail.javamailuser@localhost...

Keith, I mean this with the greatest of respect and in the absolutely
nicest of all possible ways, but if this is the best you can come up with,
I'm going to stick with "Java debugging is a solved problem".

>

By my read, three of these are real but small usability issues, four are
real but small issues that the JPDA team should look into adding to the
platform debugging interface, and the rest are things so obscure that if I
ever found myself wanting them it would be an indication that it was time
for large scale refactoring and a serious bout of unit test creation.

>

It may be a difference in our workflows. I use the debugger twice per
month, maximum, and only that because it is so difficult to create unit
test cases for IDEA plugin functionality. All of my other bug shagging is
via Ctrl-F10 in a JUnit test case.

>

If JetBrains had to invest more effort in dynamic application issue
finding, I would suggest either adding a profiler onto IDEA or
high-quality JMX integration before I recommend one more developer minute
be spent on enhancing the debugger. In terms of bang-for-the-buck,
there's just no competition.

>

--Dave Griffith



0

I think there are still plenty of us that use the debugger on a daily,
even hourly basis, especially those that construct code that is very
hard to unit test such as guis (especially dynamically built ones). I
also use it a lot in situations when I don't have control of the code.
So please don't marginalise these issues too much - at the end of the
day the debugger is a core tool in the programmers kit, and should
continue to be developed and refined as such.

N.

0

I think debugging is good enough for your monthly usage. I will often
spend several hours in a day in the debugger. I think if you used it
this much you would start to hate it as well.

Dave Griffith wrote:

Keith, I mean this with the greatest of respect and in the absolutely
nicest of all possible ways, but if this is the best you can come up
with, I'm going to stick with "Java debugging is a solved problem".


By my read, three of these are real but small usability issues, four
are real but small issues that the JPDA team should look into adding
to the platform debugging interface, and the rest are things so
obscure that if I ever found myself wanting them it would be an
indication that it was time for large scale refactoring and a serious
bout of unit test creation.

It may be a difference in our workflows. I use the debugger twice
per month, maximum, and only that because it is so difficult to
create unit test cases for IDEA plugin functionality. All of my
other bug shagging is via Ctrl-F10 in a JUnit test case.

If JetBrains had to invest more effort in dynamic application issue
finding, I would suggest either adding a profiler onto IDEA or
high-quality JMX integration before I recommend one more developer
minute be spent on enhancing the debugger. In terms of
bang-for-the-buck, there's just no competition.

--Dave Griffith

0

Stephen Kelvin wrote:

I agree that most of the suggestions are, err, a little over the top.

Still there are some improvements that could be made without much
hacking.
For example when I try to debug my custom Swing component (another area
where unit tests are difficult) Idea makes it close to impossible to
find my own member variables among the hundreds of inherited ones. Why
not have an option to group members by base classes?

Also in a chained method call, Idea could easily let me choose the one
to step into, rather forcing on me a series of step into, step out of.

And then my most hated debugger bug (because I do not learn to avoid
it): Invoke code completion in the watches window and try to use the
popup with the mouse (e.g. scrollbars) - it just vanishes. That's so
annoying.


Very well put. Especially the ability to group variables by their defining
classes would solve a major usability problem when using deep component
hierarchies. Stepping through chained method calls and nested expressions are
another hot issue, but I don't know how much "hacking" this would require.

Sascha

0

Please sign in to leave a comment.