Eclipse Conditional Breakpoints Broken?

Question

I am trying to set up a conditional breakpoint in decompiled code, but Eclipse keeps giving me the error:

Conditional breakpoint has compilation error(s)

Reason: Evaluations must contain either an expression or a block of well-formed statments

My case is pretty simple, just trying to compare against a string value. I've tried all of the following and I get errors with every single one:

myObj.toString() == "abc123"
myObj.toString().equals("abc123")
if(myObj.toString() == "abc123"){ return true; }
true == true

I've also tried every combination of having or not having a semicolon at the end of the line(s) and every combination of spacing and newlines and every combination of having or not having {} surrounding my condition. Basically, I have no idea why this isn't working...

The code I am trying to debug through is inside a jar that is decompiled with JD-Eclipse. Normal breakpoints work fine in this code.

Does anyone know what's going on here???

Solution 1

This Eclipse FAQ page contains the syntax of proper CBP definition and most common reasons for them not to work. In your case, I think the following applies:

This can happen if you are setting a breakpoint in a class whose class file does not contain a local variable table. For example, let's say you want to set a conditional breakpoint on Class.forName(String). If you have a source attachment for rt.jar the content assist will allow you to refer to the argument by its variable name, className. However, at debug runtime, the variable name will only be known if the class file contains a local variable table. Depending on the options used at compilation time, this information may have been stripped from the class file.

JD may have fabricated variable names while decompiling your jar, so using "myObj" in conditional expression produces a compile-time error.

Solution 2

Maybe conditional breakpoints are less than working in general. Consider, for example:

https://bugs.eclipse.org/bugs/show_bug.cgi?id=278146

Solution 3

It may be a bug in eclipse. What eclipse does is weave a new method or some such into the source for the file you set the breakpoint in and compile it up. If something goes wrong in this process your conditional breakpoint will mysteriously fail.

You could follow the approach I used below, running eclipse in debug to try and track down the problem:-

https://bugs.eclipse.org/bugs/show_bug.cgi?id=341232#c21

Solution 4

In case of "true == true" condition you should just add return statement:

return true == true;

For the rest of the problems missing local variable table should be the explanation. +1 to Mazaneicha for that.

Solution 5

In case of "true == true" condition you should just add return statement:

return true == true;

For the rest of the problems missing local variable table should be the explanation. +1 to Mazaneicha for that.

If you're trying to refer a method argument by its name then just try to change the name to "arg0", "arg1", etc.

For instance, you can do like this:

arg0 == null

It's easy to guess the variable name. Just put uncondidtional breakpoint and see the list of variables in the Variables view.

View more solutions

Comments

[sharakan]

Sounds promising, but OP did apparently try true == true, which should work even if the variable names are mangled!

[mazaneicha]

@sharakan You're right! Thats strange. Not sure what could be wrong with true==true.

[kand]

@mazaneicha There doesn't seem to be any content on that FAQ page. Is there some way I could actually see the table produced for my class file?

[mazaneicha]

@kand I fixed the link (the '?' needed to be url-encoded into %3F), please try it now. As far as the local var table - its what you see in the Variables view of the debugger.

[kand]

Hmm well if that's the case, Eclipse appears to have all the variables/variable names correct...

[mazaneicha]

Have you tried compiling the source you've got after decompilation and setting a BP there as opposed to the original jar? What happens then?

[studgeek]

FYI, This was made a duplicate of bugs.eclipse.org/bugs/show_bug.cgi?id=341232 which is listed as fixed in 4.3 M6.