: WARNING - support of the decompiler is now VERY LIMITED. There are no active developers. This means waiting times in the issue tracker are very long and mostly depend on community. Sorry for the inconvenience.
State: closed new: Initial state. As long as issue is in this state, the work on the issue has not yet begun. opened: Opened state means developer started working on the issue. Feature/Fix will probably be in the next release. postponed: This means developer is not working on it now, for some reason it cannot be implemented now. Issue may be opened again in the future. upgraded: Issue is in upgraded state when developer made changes to the program and new version was released. closed: This means the user is satisfied with issue results and no more changes are needed. invalid: These issues cannot be solved. ignored: Developer decided to take no action on this issue. returned: Program changes were made but user is not satisfied and returned the issue.
> What steps will reproduce the problem?
Open 71C0000 - 13.swf
Find the method which is in the exception message.
> What is the expected output? What do you see instead?
Jul 05, 2015 7:21:58 AM com.jpexs.decompiler.flash.abc.types.MethodBody convert
SEVERE: Decompilation error in §_-KG§/§_-61p§.initializer
at java.util.concurrent.FutureTask.report(Unknown Source)
at java.util.concurrent.FutureTask.get(Unknown Source)
at java.util.concurrent.FutureTask.run(Unknown Source)
at java.util.concurrent.ThreadPoolExecutor.runWorker(Unknown Source)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source)
at java.lang.Thread.run(Unknown Source)
Caused by: java.lang.StackOverflowError
at java.util.HashMap.put(Unknown Source)
+ 1000 more lines in visitCode
> What version of the product are you using? Is it "nighlty build"? Which operating system
do you have?
> Please provide any additional information below. If the problem is related to a SWF
file, attach it here, otherwise we can't help you.
This method is quite large (about 13000 instruction), but contains only about 1200 labels
(jump targets), i can't belive that they are called in 1 single chain.
In visitcode the IfType instuctions are recursively visited before visiting the
instructions in the current flow. Maybe it would be better to fisrt check the instuctions
in the current flow.
Currently the order is: ins1, ins2, ifxx, (recursive call) ins6, ins7 (return), ins4.
In the suggested way: ins1, ins2, ifxx, ins4, ins5, ins6, ins7 (now check the "ifxx"
target, but it is already processed)
For this you need to collect the possible targets to a list. Or iterate 2 times on the
instuction list. First only mark the instuctions in the current flow only, do not jump
anywhere, 2nd time is the current implementation.
The StackoverFlow in visitCode should be fixed now.
The method still timeouts.
I think the problem here is that register deobfuscator works only when there is only one
assignment to the registers. In this code, the true/false registers are assigned again -
mostly in unreachable code... I'll try it to fix it...