Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Line number selection in debug #109

Open
jmattioni opened this issue May 25, 2024 · 9 comments
Open

Line number selection in debug #109

jmattioni opened this issue May 25, 2024 · 9 comments

Comments

@jmattioni
Copy link

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
Copy link
Author

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

@jpstotz
Copy link
Collaborator

jpstotz commented May 25, 2024

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

@jmattioni
Copy link
Author

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

ModelInputStream2.zip

@nbauma109
Copy link

See #104 (comment)

@jpstotz
Copy link
Collaborator

jpstotz commented 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
Copy link
Author

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
Copy link
Collaborator

jpstotz commented 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:

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
Copy link

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
Copy link
Collaborator

jpstotz commented 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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants