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???

Alright

Did you recompile the jar from the decompiled source, otherwise the code won't match the jar, e.g. local variable names – Balance

Hmm but I get a different error saying variable names are wrong when I try to use a variable name that doesn't exist in the source... – Alright

Step one is to figure out if decompiling is the problem. Does setting a conditional break point in 'normal' code in an Eclipse project work? – Unformed

So yea, it appears that conditional break points work in my normal code... Must be something with the decompiled code then... – Alright

I have log messages stating outputting specific text. Yet when I debug with a conditional breakpoint for that very value - the breakpoint never occurs - using F11 Debug. Notthing. Give me Visual Studio for this kind of thing any day! – Oleg

Answer 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.

Net

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

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

@Net 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? – Alright

@Alright 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. – Net

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

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? – Net

Answer 2

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

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

Henslowe

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. – Tibbetts

Answer 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

Tunis

Answer 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.

Jotunheim

Answer 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.

Jotunheim

Answer 6

Just adding up what might help others as I have just solved this after some time. I am using JD-Eclipse for debugging, too, when I get this problem.

Make sure that all the necessary jar files are in Classpath. Your conditional statement may be very simple, such as "return true"; but once the "conditional breakpoint" checkbox is checked, it could be that (I can't be sure either) Eclipse debugger will check that Eclipse project's classpath against the larger scope and not just that "return true" line.

Since I'm using JD-Eclipse, I didn't bother to add all the necessary jar files. The problem was solved after I added the jar files in the project's classpath

If you're using remote debugging, you can also try to configure so that your Eclipse project's JDK is compatible with target JVM's JRE.

Dextro