Graphviz dot.exe running forever

[arm-in]

Please allow me a question:

• Given an *.exe file that I would like to decompile 32bit x86 Windows PE Visual Studio 6 C++

• File Size is 1600 KB

• RetDec is taking about 1 hour for decompilation.

• Now RetDec is emitting 7485 example.exe.c.cfg.function_123456.dot files (control flow) 13.6 MB in total Graphviz is taking some time to generate the PNGs

• The example.exe.c.cfg.entry_point.dot is also no problem

• RetDec is also emitting 1 example.exe.c.cg.dot this file is troublesome

  • graphviz-2.38.msi (latest official release) was running forever and crashing at some point (> 8 hours)
  • Graphviz 2.41.90 (from appveyor) also takes lots of time (1.5 hours, see below)
  • I was trying to tweak the command line parameters, e.g. dot.exe -Tpng -O -v -Gmaxiter=2 -Gmclimit=2 -Gnslimit=2 -Gnslimit1=2 example.exe.c.cg.dot Most probable those parameters are not correct. But at least dot.exe is running through to the end. But I have the feeling that there are too many nodes, edges, whatsoever. The output PNG is unreadable.

Console output:

network simplex: 7639 nodes 20716 edges maxiter=2147483647 balance=1
[...]
network simplex: 7639 nodes 20716 edges 3869 iter 1.21 sec
[...]
mincross Call graph of the module.: 10888773 crossings, 4714.91 secs.
network simplex:  353568 nodes 536598 edges maxiter=16366 balance=2
[...]
network simplex: 353568 nodes 536598 edges 16366 iter 852.99 sec
routesplines: 22241 edges, 381535 boxes 89.02 sec
Using render: cairo:cairo
Using device: png:cairo:cairo
dot: graph is too large for cairo-renderer bitmaps. Scaling by 0.0770205 to fit
dot: allocating a 51710K cairo image surface (32767 x 404 pixels)
gvRenderJobs Call graph of the module.: 8.80 secs.

=> Which version of Graphviz is recommended for Windows? => Is the complexity correct? 353568 nodes 536598 edges? => How to speed up computation of dot.exe? => How to increase the pixel size of the PNG image? Which render engine? Better switch to a vector format? => Maybe only show the two or three call levels below main() to get an impression / overview?

[s3rvac]

Hi. Unfortunately, when the decompiled code is huge, call graphs (.cg.dot files) and control-flow graphs (.cfg.dot files) may also be huge. The reason is that at present, we emit all the available information into the graphs, which can make them very big. To solve this, the graphs would have to be somehow split or parts of them would have to be abstracted away. Frankly, I am unsure if we ever get to do this as we do not usually use these graphs.

Anyway, let me answer your questions:

Which version of Graphviz is recommended for Windows?

The latest official release.

Is the complexity correct? 353568 nodes 536598 edges?

Unfortunately, it can be when the decompiled code is huge (see above).

How to speed up computation of dot.exe?

I do not know. It is a third-party tool. We have never really looked into that.

How to increase the pixel size of the PNG image? Which render engine? Better switch to a vector format?

You can run retdec-decompiler.py with --graph-format svg, which will produce SVG images (vector) instead of PNG images (bitmap). Or, alternatively, if you do not want to run the whole decompilation from scratch, you can just convert the .dot files with dot.exe -Tsvg input.dot -o output.svg.

Maybe only show the two or three call levels below main() to get an impression / overview?

Yes, than would be an option.

[arm-in]

Thank you for your response! I've been playing around further. It seems that running "doxygen" over the .exe.c. is more efficient. The caller graphs are referring to parent, children, etc. Navigation is more gracefully than with one monolithic graph, at least for a project in that size. Still investigating...

[arm-in]

doxygen is just fine, after some adjustments to the doxyfile. Now counting 300MB in 15000 files (html + png), but better than one monolithic graph.