JPEXS Free Flash Decompiler Issue Tracker

If you are looking for the decompiler itself, visit

: The issue tracker is now writable again and logged users can download files too. But note that our support is very LIMITED.

List of issuesList of issues

#961 Invalid recursion in Graph.finalProcess
Author: developer honfika
Date created:
Type: bug
Visibility: Everybody
Assigned to:
State: closed Help

> 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
State: upgraded→closed