search

ecd-plugin / ecd

An Eclipse Plugin to integrate different Class Decompiler seamlessly into the development workflow
Eclipse Public License 1.0
264 stars 57 forks source link

Debuging with ECD doesn't open the class in ECD on eclipse 2018-09 and later #58

Open gayanper opened 5 years ago

gayanper commented 5 years ago

When debugging a class without the source (specially eclipse RCP application), when clicking on a stacktrace the file is not opened with ECD. Instead the file is opened with not source found class editor. As a workaround to get this working, i need to open the class which belongs in the debug stack by OpenType which opens the class in ECD, after closing it if i click the debug stack again, then file is opened in ECD and the debug line is highlighted.

RobertZenz commented 5 years ago

I believe that this should be a duplicate of #43.

gayanper commented 5 years ago

@RobertZenz i don't think they are exactly the same, because in this issue, "class without source" is set to ECD it self.

helospark commented 5 years ago

I occasionally see this also and it is quite annoying when happens.

It may have something to do with multiple projects/modules open with different version of the same jar (dependency) attached, but I don't really have a reliable repro for it. Usually it helps if I close down other projects and restart the debugging.

RobertZenz commented 5 years ago

Mh, okay. Personally I haven't seen this so I'm not sure what to make of it.

gayanper commented 5 years ago

Will try to dig in if i find some time and post the details or a PR if possible

davidmichaelkarr commented 5 years ago

I occasionally see this also and it is quite annoying when happens.

It may have something to do with multiple projects/modules open with different version of the same jar (dependency) attached, but I don't really have a reliable repro for it. Usually it helps if I close down other projects and restart the debugging.

Personally, the ECD is working fine for me, but I was helping a dev with a problem yesterday, and it was refusing to decompile a particular class for her. In fact, that class was available in two different versions of the artifact, with slightly different FQCNs, and neither was decompiling. When I attempted to open the same class in my Eclipse, it only saw one of the ones that she was seeing, and it had no trouble decompiling it. She has the same version of Eclipse and ECD that I have, and I believe the ECD configs are identical also. The difference here is the factor you allude to, with two different versions of the artifact in scope.

RobertZenz commented 5 years ago

@davidmichaelkarr There is a certain caching mechanism which I have not looked at, so maybe the cache got bad on that one and confused the plugin. But I'm not sure about that.

helospark commented 5 years ago

@davidmichaelkarr If this happens next time, please try to set "Search for duplicate source files on the path" option, I have a suspicion that it helps. You can set it like: https://stackoverflow.com/a/23054379/8258222 (I was meaning to try this for a while myself, but lately I'm not working on projects, where this issue occurres)

davidmichaelkarr commented 5 years ago

On Tue, Jan 22, 2019 at 9:50 AM Helospark notifications@github.com wrote:

@davidmichaelkarr https://github.com/davidmichaelkarr If this happens next time, please try to set "Search for duplicate source files on the path" option, I have a suspicion that it helps. You can set it like: https://stackoverflow.com/a/23054379/8258222

Note that when I was seeing this problem on the other dev's computer, we weren't even running in the debugger, we were just trying to inspect the decompiled source to see why a particular log message was coming out. We weren't in a situation where we could have stepped through the code in the debugger. All we did was do "Open Type" and enter the desired class name.

jameyg42 commented 5 years ago

FYI - i had the same apparent behavior (fresh 2018-12 install, fresh workspace), and fixed the issue by simply marking ECD as the default editor for .class without source files

gayanper commented 4 years ago

I tried this with eclipse 4.14 and 4.15 milestone as well. And debugged the jdt code as well. Seems like jdt doesn’t even try to open the class file. I think thats because how the new source lookup happens.

I even had tried with a simple java project to see this. It didn’t worked

jmiserez commented 4 years ago

Unchecking the option Java -> Debug -> "Use advanced source lookup (JRE 1.5 and higher)" checkbox resolves this issue for me.

Just setting the default editor to the decompiler seems to work too, but I noticed that sometimes the wrong .class files would be decompiled when debugging.

gayanper commented 4 years ago

Nope it didn't worked for me. I will try to share my project later.

gayanper commented 4 years ago

Try to step into RMObjectBuilder constructor for example. workbench.zip

gayanper commented 4 years ago

@RobertZenz any update on the issue ? any reasons why the ECD is not even tried when debugging in eclipse 4.14 ?

helospark commented 4 years ago

This was caused by this Eclipse JDT change: https://github.com/eclipse/eclipse.jdt.debug/commit/6ec6201fa7488a685c25febb778dadaf19d9f0b4 https://bugs.eclipse.org/bugs/show_bug.cgi?id=534891

I have reverted this change locally, then class decompiler is working correctly. I have not seen any regression from reverting. The example attached to the Eclipse ticket works when I reverted the change, however there may be some other regeression cases (?). I guess the best thing would be to raise this on the Eclipse Bugzilla.

gayanper commented 4 years ago

This was caused by this Eclipse JDT change: eclipse/eclipse.jdt.debug@6ec6201 https://bugs.eclipse.org/bugs/show_bug.cgi?id=534891

I have reverted this change locally, then class decompiler is working correctly. I have not seen any regression from reverting. The example attached to the Eclipse ticket works when I reverted the change, however there may be some other regeression cases (?). I guess the best thing would be to raise this on the Eclipse Bugzilla.

Did you try this on a maven project or none maven project when you were testing ?

helospark commented 4 years ago

@gayanper I tried with the project you attached (Maven project with some jars added manually to the classpath in Eclipse), the project attached to the Eclipse ticket (which is just a plain Eclipse project) and a Spring Boot app (which is fully Maven). It was working in all cases as expected.

In case of Maven with source attachement, it is working because the ECD can delegate to source attachment if there is one, only decompiles class if no source found.

gayanper commented 4 years ago

@helospark May be this is what enabled the MavenRuntimeClasspathProvider to resolve source paths. I have done some change and reported some bugs as well. https://bugs.eclipse.org/bugs/show_bug.cgi?id=561554 https://bugs.eclipse.org/bugs/show_bug.cgi?id=559797

helospark commented 4 years ago

@gayanper The version I tested this change doesn't have your changes yet, and I'm not sure how MavenRuntimeClasspathProvider connected to all of this. Did your fix to m2e also resolves the issue? - not entirely clear from the ticket

gayanper commented 4 years ago

@helospark not entirely, there are some problems when debugging which i'm looking right now. But the this issue here, i manage to fix it from m2e. So its not an issue in ECD plugin.

nbauma109 commented 2 years ago

Unchecking the option Java -> Debug -> "Use advanced source lookup (JRE 1.5 and higher)" checkbox resolves this issue for me.

This is what worked for me ! Thanks @jmiserez

aakifshamsi commented 1 year ago

Unchecking the option Java -> Debug -> "Use advanced source lookup (JRE 1.5 and higher)" checkbox resolves this issue for me.

Just setting the default editor to the decompiler seems to work too, but I noticed that sometimes the wrong .class files would be decompiled when debugging.

Perhaps I followed steps till this point, and the combo worked for me.