What exactly does "skipped breakpoint at ... because it happened inside debugger evaluation" mean?

Answered

Note: I have looked at this https://intellij-support.jetbrains.com/hc/en-us/community/posts/115000622624--skipped-breakpoint-at-because-it-happened-inside-debugger-evaluation- and this https://youtrack.jetbrains.com/issue/IDEA-178509#comment=27-2426329

Background:

I am remote debugging a core java app using Intellij and this message keep flashing on the status bar.

Also I have unchecked "Enable 'toString()' object view. It seems that this happens when there are conditional breakpoints.

1. If this is due to 'toString()' evaluations, why does it happen when the setting is disabled?

2. When exactly does 'toString()' evaluation happen? I my case the program hasn't hit any breakpoints and is running. I didn't expect anything shown in the debugger window to be evaluated when a breakpoint is not hit.

3. Is it possible that Intellij is mis-interpreting something from the remote JVM? Or some incompatibility due to Oracle vs Open JDK?

10 comments
Comment actions Permalink

Hi, this message is shown if debugger is stopped on a suspend all breakpoint and evaluates the code which hits another breakpoint. In your case most probably the breakpoint condition evaluation triggers another breakpoint.

0
Comment actions Permalink

Thanks. Though this make sense and probably the case in some scenarios, it doesn't look like it is the case for me.

I have a 'do while( true ) { receive(); }' loop where messages are received via tcp and few unconditional breakpoints in 'receive()'. From the status bar message these are being skipped. 'receive()' is not called from anywhere else.

Also I had a case where another breakpoint in a function called by 'receive()' was hit and the call stack indicated that a breakpoint in 'receive()' should have been hit before the one that was triggered.

 

0
Comment actions Permalink

If you can create a test case project I could have a look.

0
Comment actions Permalink

My plan is to try something more primitive (jdb?) and observe the wire protocol to see if I can get a sense of what is going on. Will update here. Thanks.

0
Comment actions Permalink

I have the same issue with a slightly complex conditional breakpoint.

All my breakpoints are 'Suspend All' so no thread can be running when my program is stopped (which I assume is a condition for the debugger to be 'evaluating' something)

I have a breakpoint with this condition which breaks correctly:

`value.getIdentifier().equals("Power")`

When I change the condition to this, it always fails with "skipped breakpoint at ... because it happened inside debugger evaluation":

`value.getIdentifier().equals("Power")&&((BooleanRegisterValue)value).getState()`

The method getState has a single statement returning a boolean field which has no breakpoint.

Also, this is in plain Java. No remote, Maven, or anything. (Ignoring the localhost debugging connection)

 

(IC-201.7846.76 running on JetBrains VM, my programming running on OpenJDK 11.0.7+10-post-Ubuntu-2ubuntu218.04)

0
Comment actions Permalink

I don't see the relevance. That thread is about the program suspending on a breakpoint but other threads running and skipping breakpoints. I'm having no such problem.

0
Comment actions Permalink

While "suspend all" breakpoint is evaluating its condition, it resumes all threads. During this other breakpoints may be hit (they will be skipped).

Switching to "suspend thread" resolves this by evaluating the condition only resuming one thread.

0
Comment actions Permalink

There's no thread to resume. The program is running from the start and skipping the breakpoint. Besides I already tried both (suspend thread is my default policy)

0
Comment actions Permalink

If it does not work with "suspend thread" breakpoints, please file a bug, we'll need more details. Thanks!

0

Please sign in to leave a comment.