debugger problems in 7.0.4

has anybody experienced debugger problems in 7.0.4?
it is driving me crazy today...
one entry of an array field suddenly contains data that can only arrive there via exactly one method.
I set a breakpoint in this method, but IDEA never stops there.
Nevertheless, when I arrive in another breakpoint, the data is in there.

WTF? ;)

I'm downloading Eclipse now to check there - will let you know the result...

9 comments
Comment actions Permalink

I set a breakpoint in this method, but IDEA never stops there.
Nevertheless, when I arrive in another breakpoint, the data is in there.


I had a similar issue with code like this:

ThreadUtils.invokeInEventDispatchThread(new Runnable() {
public void run() {
doSomething(); // here is a breakpoint
}
}

When I step over (F8) the invokeInEventDispatchThread()-method, the
breakpoint in the runnable will NOT be hit, but the code will be executed.

Tom

0
Comment actions Permalink

Hi Michael,

Not enough data to guess what might be wrong. Could you give any details?

--
Best regards,
Eugene Zhuravlev
Software Developer
JetBrains Inc.
http://www.jetbrains.com
"Develop with pleasure!"

"Michael Damberger" <michael.damberger@t-online.de> wrote in message
news:23270881.9291224161752626.JavaMail.jive@app4.labs.intellij.net...

has anybody experienced debugger problems in 7.0.4?
it is driving me crazy today...
one entry of an array field suddenly contains data that can only arrive there via exactly one method.
I set a breakpoint in this method, but IDEA never stops there.
Nevertheless, when I arrive in another breakpoint, the data is in there.

>

WTF? ;)

>

I'm downloading Eclipse now to check there - will let you know the result...



0
Comment actions Permalink

ThreadUtils.invokeInEventDispatchThread(new Runnable() {
public void run() {
doSomething(); // here is a breakpoint
}
}

>

When I step over (F8) the invokeInEventDispatchThread()-method, the breakpoint in the runnable will NOT be hit, but the code will
be executed.


During stepping breakpoints in other threads than the current one are ignored (stepping means implicit 'thread' filter that
restricts events to the current thread). In order for breakpoints in other threads to be honored use F9 (resume) or alt-F9 (run to
cursor).


--
Best regards,
Eugene Zhuravlev
Software Developer
JetBrains Inc.
http://www.jetbrains.com
"Develop with pleasure!"


0
Comment actions Permalink

Thanks for the explanation. Where can I find the option to deactivate the
current behaviour ?

Tom

0
Comment actions Permalink

The problem comes from field watchpoints.
This is how I found out:
first I put a System.out in the method where the breakpoints were not executed, just too make 100% sure.
Yes, the system out was visible on the console and the breakpoint on the System.out statement was ignored. I was using F9 & no threads involved.
Next I added a statement
new Exception("debug").printStackTrace();

this is what I got:
java.lang.Exception: debug
at cdn.dbal.cache.CacheEntry.set(CacheEntry.java:30)
at cdn.dbal.cache.ParcelCache.cacheParcel(ParcelCache.java:332)
at cdn.dbal.cache.ParcelCache.loadFilteredParcel(ParcelCache.java:216)
at cdn.dbal.cache.ParcelCache.getParcel(ParcelCache.java:79)
at cdn.dbal.Dbal.getStreetName(Dbal.java:1288)
at cdn.dataunits.Segment.getName(Segment.java:379)
at cdn.dataunits.Segment.toString(Segment.java:1039)
at com.intellij.rt.debugger.BatchEvaluatorServer.evaluate(BatchEvaluatorServer.java:16)
parcelID = -25161984
at cdn.dbal.Dbal.getStreetName(Dbal.java:1288)
at cdn.dataunits.Segment.getName(Segment.java:379)
at cdn.mapcompiler.debug.DebugSegmentReader.main(DebugSegmentReader.java:68)

the parcelID output is from my System.out
You see: com.intellij.rt.debugger.BatchEvaluatorServer.evaluate
I thought - this is suspicious, and I removed all breakpoints, and also three field watchpoints that I had added,
on fields that were used in the method I tried to debug.

After removing all breakpoints, and setting just a few new ones (normal ones, no field watchpoints), it worked normally again.

My conclusion: I strongly suspect that field watchpoints are buggy, and I will never use them again ;)

0
Comment actions Permalink

No options there. Just use F9 if you have several candidate threads that can hit the breakpoint.

--
Best regards,
Eugene Zhuravlev
Software Developer
JetBrains Inc.
http://www.jetbrains.com
"Develop with pleasure!"

"Tom" <noname@jetbrains.com> wrote in message news:gd7vp3$el5$1@is.intellij.net...

Thanks for the explanation. Where can I find the option to deactivate the current behaviour ?

>

Tom



0
Comment actions Permalink

I see now. The problem has nothing to do with field watchpoints (they work as expected), but rather with the combination of debugger
settings and code being debugged.
The com.intellij.rt.debugger.BatchEvaluatorServer provides optimization in evaluation of "toString()" methods for debugger views.
Some of the objects being debugged have non-trivial toString() implementations with side effects (see the stacktrace below). Both
options "enable toString() object view" and "alternate collections view" involve method calls in the target VM and if these options
are on, side effects are possible. If you are unsure about toString() implementation, it's better to turn it off. The side-effects
will be avoided at the cost of less convenient data presentation.


--
Best regards,
Eugene Zhuravlev
Software Developer
JetBrains Inc.
http://www.jetbrains.com
"Develop with pleasure!"

"Michael Damberger" <michael.damberger@t-online.de> wrote in message
news:18795585.13341224234763703.JavaMail.jive@app4.labs.intellij.net...

The problem comes from field watchpoints.
This is how I found out:
first I put a System.out in the method where the breakpoints were not executed, just too make 100% sure.
Yes, the system out was visible on the console and the breakpoint on the System.out statement was ignored. I was using F9 & no
threads involved.
Next I added a statement
new Exception("debug").printStackTrace();

>

this is what I got:
java.lang.Exception: debug
at cdn.dbal.cache.CacheEntry.set(CacheEntry.java:30)
at cdn.dbal.cache.ParcelCache.cacheParcel(ParcelCache.java:332)
at cdn.dbal.cache.ParcelCache.loadFilteredParcel(ParcelCache.java:216)
at cdn.dbal.cache.ParcelCache.getParcel(ParcelCache.java:79)
at cdn.dbal.Dbal.getStreetName(Dbal.java:1288)
at cdn.dataunits.Segment.getName(Segment.java:379)
at cdn.dataunits.Segment.toString(Segment.java:1039)
at com.intellij.rt.debugger.BatchEvaluatorServer.evaluate(BatchEvaluatorServer.java:16)
parcelID = -25161984
at cdn.dbal.Dbal.getStreetName(Dbal.java:1288)
at cdn.dataunits.Segment.getName(Segment.java:379)
at cdn.mapcompiler.debug.DebugSegmentReader.main(DebugSegmentReader.java:68)

>

the parcelID output is from my System.out
You see: com.intellij.rt.debugger.BatchEvaluatorServer.evaluate
I thought - this is suspicious, and I removed all breakpoints, and also three field watchpoints that I had added,
on fields that were used in the method I tried to debug.

>

After removing all breakpoints, and setting just a few new ones (normal ones, no field watchpoints), it worked normally again.

>

My conclusion: I strongly suspect that field watchpoints are buggy, and I will never use them again ;)



0
Comment actions Permalink

I see, that makes sense - thanks for the information.

What do you think about this idea: a "panic button" somewhere in IntelliJ where you switch into a safe mode,
which automatically deactivates all potentially harmful behavior, like evaluating toString methods in debugger.
So, if you are in high stress, and run into such kind of a problem - you can solve it by just hitting the "panic button"


best regards,
Michael

0
Comment actions Permalink

one more note... I still wondered why the problem went away after I removed the field watch points.
My explanation: the field watch point was exactly what caused the toString evaluation before reaching the method breakpoint.
Removing the field watch point removed the toString evaluation, and this way, removed my problem ;)

0

Please sign in to leave a comment.