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

[3.5.0] Decompiling fails with Procyon for big files - and line alignment does not work. #104

Open
mora-phi opened this issue Apr 12, 2024 · 12 comments

Comments

@mora-phi
Copy link

Hi,

Since latest version (3.5.0), I get "java.lang.OutOfMemoryError: Java heap space" when trying to decompile big Java files with Procyon. The file is around 12 000 lines once decompiled.
When I try to decompile with the other ones, it works... But line alignment does not and therefore debugging is impossible.

In previous version (3.3.0 I think, I had it in a previous version of eclipse, before the problems that occurred in #103) everything worked well.

Thanks.

@jpstotz
Copy link
Collaborator

jpstotz commented Apr 12, 2024

How much heap space is allowed in your Eclipse? May be the new Eclipse version simply requires more RAM and thus for ECD/Procyon the remaining heap is too small for such a large file?
Check the -Xmx Configuration option of your Eclipse (e.g. in About -> Installation Details).

In .metadata/.log in your Eclipse workspace directory there should be a stack trace of this error. Can you please post it?

@mora-phi
Copy link
Author

mora-phi commented Apr 12, 2024

Hi,

I have eclipse with the following:
-Xms512m
-Xmx2048m

Before opening the issue I also tried with Xmx 4096 but the result was the same.

The stack is the following (inside an ENTRY showing "Editor could not be initialized."):

!SUBENTRY 1 org.eclipse.ui.workbench.texteditor 4 0 2024-04-12 14:30:08.629
!MESSAGE Editor could not be initialized.
!STACK 0
java.lang.OutOfMemoryError: Java heap space
	at java.base/java.lang.StringLatin1.toChars(StringLatin1.java:74)
	at java.base/java.lang.String.toCharArray(String.java:4103)
	at org.sf.feeling.decompiler.editor.BaseDecompilerSourceMapper.findSource(BaseDecompilerSourceMapper.java:213)
	at org.sf.feeling.decompiler.editor.DecompilerSourceMapper.findSource(DecompilerSourceMapper.java:65)
	at org.sf.feeling.decompiler.editor.JavaDecompilerClassFileEditor.doOpenBuffer(JavaDecompilerClassFileEditor.java:160)
	at org.sf.feeling.decompiler.editor.JavaDecompilerClassFileEditor.doOpenBuffer(JavaDecompilerClassFileEditor.java:141)
	at org.sf.feeling.decompiler.editor.JavaDecompilerClassFileEditor.doOpenBuffer(JavaDecompilerClassFileEditor.java:134)
	at org.sf.feeling.decompiler.editor.JavaDecompilerClassFileEditor.doSetInput(JavaDecompilerClassFileEditor.java:382)
	at org.eclipse.ui.texteditor.AbstractTextEditor.lambda$1(AbstractTextEditor.java:3171)
	at org.eclipse.ui.texteditor.AbstractTextEditor$$Lambda$887/0x00000008009322f0.run(Unknown Source)
	at org.eclipse.jface.operation.ModalContext.runInCurrentThread(ModalContext.java:434)
	at org.eclipse.jface.operation.ModalContext.run(ModalContext.java:354)
	at org.eclipse.ui.internal.WorkbenchWindow.lambda$7(WorkbenchWindow.java:2335)
	at org.eclipse.ui.internal.WorkbenchWindow$$Lambda$1586/0x0000000800d01f18.run(Unknown Source)
	at org.eclipse.swt.custom.BusyIndicator.showWhile(BusyIndicator.java:67)
	at org.eclipse.ui.internal.WorkbenchWindow.run(WorkbenchWindow.java:2332)
	at org.eclipse.ui.texteditor.AbstractTextEditor.internalInit(AbstractTextEditor.java:3188)
	at org.eclipse.ui.texteditor.AbstractTextEditor.init(AbstractTextEditor.java:3213)
	at org.eclipse.jdt.internal.ui.javaeditor.ClassFileEditor.lambda$0(ClassFileEditor.java:656)
	at org.eclipse.jdt.internal.ui.javaeditor.ClassFileEditor$$Lambda$886/0x000000080096da58.run(Unknown Source)
	at org.eclipse.jdt.core.JavaCore.lambda$0(JavaCore.java:6142)
	at org.eclipse.jdt.core.JavaCore$$Lambda$885/0x0000000800964a50.call(Unknown Source)
	at org.eclipse.jdt.internal.core.JavaModelManager.cacheZipFiles(JavaModelManager.java:5839)
	at org.eclipse.jdt.internal.core.JavaModelManager.callReadOnly(JavaModelManager.java:5828)
	at org.eclipse.jdt.core.JavaCore.callReadOnly(JavaCore.java:6126)
	at org.eclipse.jdt.core.JavaCore.runReadOnly(JavaCore.java:6141)
	at org.eclipse.jdt.internal.ui.javaeditor.ClassFileEditor.init(ClassFileEditor.java:656)
	at org.eclipse.ui.internal.EditorReference.initialize(EditorReference.java:353)
	at org.eclipse.ui.internal.e4.compatibility.CompatibilityPart.create(CompatibilityPart.java:344)
	at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
	at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:77)
	at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)

@jpstotz
Copy link
Collaborator

jpstotz commented Apr 12, 2024

The code the stack trace is referring to is creating a char[] from a StringBuffer. There is nothing special that could go wrong and we can not avoid this conversion. It simply requires twice the size of the decompiled source code as RAM because of the conversion.

As you mentioned it is a large file and Eclipse is simply running out of RAM. If you work with such large files please increase the -Xmx configuration in your eclipse.ini file e.g. to -Xmx3072m (assuming you use a 64bit Java VM, otherwise this might fail).

@mora-phi
Copy link
Author

As I said I tried with -Xmx4096m before opening the issue :-)
I just tried with -Xmx8192m just for fun and the result was the same... Also, Why would it work with the other decompilers with "only" 1024m and Procyon would need so much memory...

image

@jpstotz
Copy link
Collaborator

jpstotz commented Apr 12, 2024

Not sure what can cause such problems on Procyon. Can you share the classes you want to decompile?

@mora-phi
Copy link
Author

Hi,
I'll check if I can share them, they are from a provider with closed-source policy :-)
I'll update on monday most likely.
Thanks.

@mora-phi
Copy link
Author

Hi,
Sorry but I won't be able to provide the original class file that produces these problems as it is closed-source and not mine...

@nbauma109
Copy link

Line number realignment:

I have a PR open to fix Procyon "stretch lines" option mstrobel/procyon#60 that is used by ECD. I also have a fork of ECD that uses Procyon with "stretch lines" set to false and lets ECD realign the code.

Big file:

Try and open it with Luyten or decompile with Procyon command line. This way you'll know if the issue comes form Procyon or ECD.

@mora-phi
Copy link
Author

mora-phi commented May 7, 2024

Hi,
Opening the JAR and decompiling the class with Luyten works. It takes a little time (less than 10 seconds), and displays the class correctly.
So it seems the problems comes from ECD, not Procyon.

I'll try your fork, thanks.

@juanbomfim22
Copy link

Important

In eclipse.ini file, make below entries
-Xms512m
-Xmx2048m
-XX:MaxPermSize=1024m

from StackOverflow

@nbauma109
Copy link

Definitely not -XX:MaxPermSize=1024m. Removed since Java 8.

@juanbomfim22
Copy link

juanbomfim22 commented May 24, 2024

Definitely not -XX:MaxPermSize=1024m. Removed since Java 8.

You are absolutely right. In my case I used it for backwards compatibility with Java 7. And it worked.

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

4 participants