Line number selection in debug

[jmattioni]

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?

[jmattioni]

Code that "disappeared" when "Align code for debugging" is enabled is all on one line. The end of line delimiters were lost somehow.

[jpstotz]

Which decompiler have you used? Can you post the code that disappeared?

[jmattioni]

Decompiler selected is Procyon. Here's the class file. The problem isn't unique to this file.

ModelInputStream2.zip

[nbauma109]

See #104 (comment)

[jpstotz]

@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]

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]

Ok, I checked it. The main problem is that the source code line numbers ECD uses for reformatting the file are strange:

Line # Position : {orig=44, emitted=40/9}
Line # Position : {orig=56, emitted=44/9}
Line # Position : {orig=621, emitted=45/9}
Line # Position : {orig=68, emitted=50/9}
Line # Position : {orig=621, emitted=51/9}
Line # Position : {orig=74, emitted=55/9}
Line # Position : {orig=81, emitted=59/9}
Line # Position : {orig=82, emitted=60/9}
Line # Position : {orig=83, emitted=61/9}
Line # Position : {orig=85, emitted=62/13}
Line # Position : {orig=92, emitted=67/9}
Line # Position : {orig=94, emitted=68/43}
Line # Position : {orig=95, emitted=69/13}
...

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]

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]

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.