If you are looking for the decompiler itself, visit https://github.com/jindrapetrik/jpexs-decompiler
NEW : We have got a new blog where we post some interesting SWF internals info.
List of issues#961 Invalid recursion in Graph.finalProcess
Author: 
honfika
honfikaDate created:
Type: bug
Visibility: Everybody
Assigned to:
State: closed 
> What steps will reproduce the problem?
Open swf.swf from issue tracker.
Try to decompile §\x06\x06\x01\x07\x05\b\x05\x03\x03§ .
§\x00\x05\x00\x03\x02\x03\x06\x05\x03\x04\x03\x05§
> What is the expected output? What do you see instead?
finallProcess "never" (ok, not never, but hours or maybe years...) completes
The graph target list contains more than 90000 items. There are 2 nested loops, + this
method is called from the finalProcessAll method from a loop which iterates through the
same list, so this is at least O(n^3), but probably even more.
+this thread is not interrupted (after the 1 minute timeout), because there is no
interrupt check.. i'll add it, but it is not a solution, only a workaround to avoid high
cpu usage.
In finalProcess method the
fori.firstCommands (line 547)
and the "list" (from method arguments) are the same. Is it normal?
So the list is just growing while the for loop is iterating to higher and higher.
It is not slow, it was wrong.
finalProcees whould walk the block of the code and call self to all subblocks.
But there is for detection which takes all items before while item on the same line (based
on line info) and puts it in the for first commands. The important thing there is that it
must not move other previous for items/loops to the first commands. It should be fixed now
in the repository. It might be the cause of many of the timeouts in #963.
State: new→upgraded
Title: Graph.finalProcess very slow→Invalid recursion in Graph.finalProcess
Title: Graph.finalProcess very slow→Invalid recursion in Graph.finalProcess
Thanks.
State: upgraded→closed