Cannot set breakpoint in decompiled class during debugging

[helospark]

Description

When trying to set a breakpoint in a ECD decompiled class file, the toggle action is ignored without any log or exception.

Repro:

• Start debugging a project
• Open a class with decompiler editor
• Try to set breakpoint
• Observe there are no logs and the breakpoint is not added either

Cause

I've done a little investigation, and it may a regression after #37 .
In the DecompileUtil.mapSources method a fallback is applied in case of the "mapSource" method is not found here. This is triggered by NoSuchMethodError, however ReflectionUtil.invokeMethod fails silently here and here, therefore the code can never get to the fallback.

And the already existing sourceRange mapping is removed by this time in DecompileUtil, which later causes org.eclipse.debug to fail to find the source and ignore the add breakpoint toggle.

Another issue (?) seems to be, that the DecompileUtil is called with org.eclipse.jdt.internal.core.SourceMapper instance, not DecompilerSourceMapper which contains switchMapSource when invoked during debugging (class is opened by ctrl+shift+t -> Open Type).

Solution could be to find the correct method using ReflectionUtils.getDeclaredMethod and once the method is found call that (and not rely on the exceptions, or on switchMapSource).

This may also cause #35

If you want I can open a PR with the fix.

Installation info

ECD: 3.1.0
Eclipse: Photon (I20180611-0500)
Platform: Windows and Linux

[RobertZenz]

Thanks for the thorough report. Unfortunately I won't be able to take a look at this for the next few weeks, sorry for that delay.

[helospark]

@RobertZenz No worries.
I have opened a PR, please review it when you have some free time.

[davidmichaelkarr]

I'm seeing the same problem. I can't set breakpoints in any class files now. I hope that PR fixes it, and is released soon.

[davidmichaelkarr]

I understand the constraints of life, but is this going to be addressed? It's been almost two months now, and I still can't set breakpoints in decompiled classes. This makes some issues really annoying to track down.

[helospark]

@davidmichaelkarr Until it's merged, you can compile my branch and drop the generated jar files to Eclipse's dropin folder.
That's what I've been doing since it's a really big limitation.

[davidmichaelkarr]

As I don't build eclipse plugins very much, once I've modified my normal Eclipse installation with those modified jars, what do I do if I want to revert back to using the regular one (at some point in the future)?

[davidmichaelkarr]

Also, concerning the build instructions, there's an ambiguous point right at the beginning. It says to clone the ecd repo, then clone the update repo next to it. Then run mvn. So, I cloned your fork of the main repo, and cloned the main update repo. Both repos have a pom file. Do I run mvn in the last repo I cloned (update), or just the first one, or both?

[helospark]

@davidmichaelkarr Seems, that the instructions do not work, the update site's versions were not updated to use the snapshot, I guess they will be changed during the release process. I have compiled my version from Eclipse.

But by not compiling update site it works with Maven:

• Remove the already installed version of EclipseClassDecompiler from Eclipse
• Clone my ecd fork
• In the main pom.xml remove <module>../update/</module> line (this is the update site)
• mvn clean install in the ecd root folder (make sure that you do not have Java 9+)
• Collect all the jar files from the target folders and copy them to the dropin folder in the Eclipse's root folder (either manually, or on *nix system find -iname org.sf*.jar -exec cp {} eclipse_path/dropins/. \;
• (re)start Eclipse

To revert back, just remove the jars from dropin and install (fixed version) of ECD from Eclipse Marketplace.

[davidmichaelkarr]

Concerning the step for collecting all the jar files, there is at least one case where a jar file with the same name is present in more than one folder. Specifically, there is "org.sf.feeling.decompiler.cfr.feature/target/org.sf.feeling.decompiler.cfr-3.1.0-SNAPSHOT.jar" and "org.sf.feeling.decompiler.cfr/target/org.sf.feeling.decompiler.cfr-3.1.0-SNAPSHOT.jar". The two files are clearly different.

[helospark]

@davidmichaelkarr You should copy the non-feature ones (ex. org.sf.feeling.decompiler.cfr/target/org.sf.feeling.decompiler.cfr-3.1.0-SNAPSHOT.jar).

[davidmichaelkarr]

That worked. Thanks for the help.

[andysworkshop]

I'm also impacted by this regression. Subscribed to this issue hoping it'll be updated when we can get the fix through the Eclipse update facility.

[davidmichaelkarr]

Following the instructions provided by @helospark to build his pull request and install it locally. It worked for me. I hope the author is able to address this in the main repo soon.

[andysworkshop]

Company security settings prevent me from following the @helospark instructions. What fixed it for me was to uninstall 3.1.0 through the Eclipse UI and then download the 3.0.0 release zip from this repo and copy the 6 jars in the plugins directory to the Eclipse dropins directory. Now I've got my breakpoints back as well as mouse hover-over variable inspection that also seemed to be unreliable at best in 3.1.0.

[beirtipol]

@andysworkshop I've been screaming at Eclipse for the past few months trying to figure out why it had stopped working. I'd forgotten I was using an Oomph installer which auto-updated the plugins. Finally got breakpoints back again. Thanks for figuring out that 3.0 works!

[mojo2012]

When will a fixed version be released? It's been broken a very long time now ... :-(

[RobertZenz]

Sorry for the late response, I was quite busy/occupied for the most time. This did not go unnoticed (nothing does), and I actually managed to get some spare time to spent on this today or tomorrow. If I have not looked at this by Friday, feel free to remind me of this by using some expletives, I agree that this has been sitting around for far too long.

[beirtipol]

How many fucking expletives would you like @RobertZenz? :)

Many thanks for keeping this tool going, it's been invaluable over the years

[RobertZenz]

All of 'em!

[RobertZenz]

Looks good to me and seems to work. Thank you very much.

[RobertZenz]

I've just published 3.1.1 with this fix and it should already be available for automatic updating.

[beirtipol]

Fucks sake @RobertZenz now I've got to fucking update the fucking plugin instead of fucking waiting til fucking Friday. Why can't you be more like other fucking open source project contributors and just fucking ignore the problems?

Disgraceful;)

[beirtipol]

Actually, jokes aside - any chance you can push the updatesite in to the latest tag so I can manually download? I'm still fighting corporate proxy issues so can't use the Eclipse update mechanism to download unfortunately:/

[RobertZenz]

Ahrm, the update-Project should be up to date and you can get the releases from this repository.

[andysworkshop]

Most open source projects:

1. Silence
2. Works for me
3. Fix it yourself
4. (2) so go and (3)

Happy to say 3.1.1 is working. Cheers Bob!