Repository navigation
Line number selection in debug #109
Description
I have the option enabled to "Output original line numbers in the comments". The problem is that debug position in the source code is based on the editor line numbers and not the original line numbers.
When I attempt to enable the option "Align code for debugging" huge portions of the source code disappear and are replaced with empty lines containing only line number comments.
Is there any way that the original line numbers, as found in the comments, can be used to set file position during debugging?
Activity
jmattioni commentedon May 25, 2024
Code that "disappeared" when "Align code for debugging" is enabled is all on one line. The end of line delimiters were lost somehow.
jpstotz commentedon May 25, 2024
Which decompiler have you used? Can you post the code that disappeared?
jmattioni commentedon May 25, 2024
Decompiler selected is Procyon. Here's the class file. The problem isn't unique to this file.
ModelInputStream2.zip
nbauma109 commentedon May 25, 2024
See #104 (comment)
jpstotz commentedon May 26, 2024
@jmattioni Thanks for providing the class file.
Are you sure the code is really gone? When I decompile the class file using Procyon with ECD 3.5.0 and option "Align for Debugging" enabled I am getting a very huge line 68: more than 260KB of code are included in this line.
This may be caused by missing line number tag in the byte code. Not sure if this is correct or not.
jmattioni commentedon May 26, 2024
After my initial report I added a comment that the "missing" source code wasn't actually missing, but rather it was all on one line w/o line breaks. With align off all the source code is there, formatted correctly, and the line number comment tags are correct. Turn on align and most of the source ends up on one line. Didn't notice this initially until I scrolled to the right.
jpstotz commentedon May 26, 2024
Ok, I checked it. The main problem is that the source code line numbers ECD uses for reformatting the file are strange:
As you can see before and after line 68 ECD recognizes code that belongs to line 621 and this seems to confuse the line reformatter.
My guess is that there was a simple private function on line 621 that got inlined by the Java compiler into multiple other methods (may be a simple field getter?). Therefore the original line numbers are so strange.
The only way I see to handle this situations would be to filter out non-continuous line numbers to avoid this type of problems.
nbauma109 commentedon May 26, 2024
It's a private field declaration/initialization at line 621 in between other method declarations. I have a PR open at Procyon to manage this mstrobel/procyon#60 (2nd bullet point).
For the realignment, will send a PR to fix.
jpstotz commentedon May 26, 2024
Because of this Procyon is not the only affected decompiler. The output of JD-Core looks similar.
My first approach was to remove the line numbers that don't fit into the ascending order: 0d2c038
At the moment this only works if the "hiccup" is a much high line number like in the example. The possible case that it is a much lower line number isn't currently considered in this code.