jpstotz
commented
4 months ago Another possibility would be that the source code wasn't properly aligned to the expected line properties. And when you created the breakpoint the actual breakpoint was set somewhere else because the displayed code does not correspond to the code Eclipse internally expected to be.
Which decompiler have you used? Make sure not to use FernFlower or CFR when you want to set breakpoints (these two don't properly output the code for debugging). I would also recommend enabling the ECD setting "Align code for debugging" (this property is automatically active if you are in Debugging perspective).
Using Eclipse 2024-03 and the latest ECD.
The title is vague because it's impossible to put this concisely. I'll describe it with a basic example.
I'm debugging a problem with embedded Tomcat startup. I've set breakpoints in "org.apache.catalina.core.StandardContext" using the decompiler view of that class.
When I run the service using embedded Tomcat, it hits the breakpoints, but with the use of the "org.springframework.boot.web.embedded.tomcat.TomcatEmbeddedContext" class, which is a subclass of StandardContext. As a result, it shows an editor buffer for "TomcatEmbeddedContext(StandardContext)" and shows "Source not found" and "Edit Source Lookup Path...".
This is not fatal, just really tedious. I can see the stacktrace, and it shows the line number in the class, so in the Decompiled view, I can go to that line, and if I do "Step Over", I can see the line number in the stacktrace change, but of course nothing changes in the Decompiler view, because the debugger doesn't think we're in that class. The Variables pane is all correct, I just have to go back and forth from the stacktrace to the Decompiled view to see where I am.
It seems pretty likely the problem is due to the use of the subclass.
Is there any way to mitigate this?