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

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.

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?

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)

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).

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

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

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.

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

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.

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.

Important

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

from StackOverflow

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

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.

Navigation Menu

Repository navigation

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

Metadata

Assignees

Labels

Projects

Milestone

Relationships

Development

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

Description

Activity

jpstotz commented on Apr 12, 2024

mora-phi commented on Apr 12, 2024

jpstotz commented on Apr 12, 2024

mora-phi commented on Apr 12, 2024

jpstotz commented on Apr 12, 2024

mora-phi commented on Apr 12, 2024

mora-phi commented on Apr 15, 2024

nbauma109 commented on May 7, 2024

mora-phi commented on May 7, 2024

juanbomfim22 commented on May 24, 2024

nbauma109 commented on May 24, 2024

juanbomfim22 commented on May 24, 2024

Metadata

Metadata

Assignees

Labels

Projects

Milestone

Relationships

Development

Issue actions