|Anonymous | Login||2017-11-18 23:53 EST|
|Main | My View | View Issues | Change Log | Roadmap | My Account|
|View Issue Details|
|ID||Project||Category||View Status||Date Submitted||Last Update|
|0002478||graphviz||GVedit||public||2014-08-08 20:45||2014-08-17 18:59|
|Summary||0002478: Gvedit crashes when trying to open my gv script|
|Description||I'm developing a mips to x86-64 binary translator (dynamic recompiler) and to track the bugs in my recompiler, I added some stuff to output a .gv file which describes a CFG with disassembly for both MIPS and x86-64 code.|
The first file is "cfg_sb_0xA3FB0720.gv". It is a entry function to start a mips superblock, not the real stuff. I can open it and have a graph. But sometimes if I close it then reopen it, Gvedit may crash.
I attached the .png file for the first file so you can have a general idea of what I'm trying to get.
The second file is "cfg_sb_0xA3FB0800.gv". I always fail to open it with Gvedit. If I strip a lot of subgraphes inside, I can then open it but it is not very helpful.
|Steps To Reproduce||just open "cfg_sb_0xA3FB0800.gv".|
|Tags||No tags attached.|
|Attached Files|| cfg_sb_0xA3FB0720.7z (Attachment missing)|
cfg_sb_0xA3FB0800 - Incomplete.png (Attachment missing)
cfg_sb_0xA3FB0840-201408166.7z (Attachment missing)
sb_0xA3FB0840.gv-20140818.pdf (Attachment missing)
I was unable to reproduce the crash when re-opening the first file. If you can identify some actions that reliably cause the crash and let me know, I can track it down.
As for the second graph, the main problem is that the code for handling non-trivial flat edges between adjacent nodes fails if either node has record shape. The code has been recently changed (see bug 2471) to print a warning and fail gracefully.
Although in reality the bug is still there, the chances of it begin fixed are very small. The main reason is that we view record shapes as being superseded by HTML-like labels. As you are generating the DOT files, it should be fairly straightforward to amend your code to make the changes.
For example, node n_98 can be rewritten as
n_98 [shape=none margin=0 label=<<TABLE CELLBORDER="0" CELLSPACING="0" CELLPADDING="4">
<TR><TD port="b" colspan="3"> </TD></TR><HR/>
<TR><TD port="0_2" align="left" colspan="3">Source: 0x089000C0 [ 14600002 bne $v1, $zr, 0x089000CC]</TD></TR><HR/>
<TR><TD port="1_2" align="left">0xA3FB08CD( 5)</TD><VR/>
<TD port="2_2" align="right">______________________00000059B9</TD><VR/>
<TD port="3_2" align="left">mov ecx, 0x59</TD></TR><HR/>
<TR><TD port="0_3" align="left" colspan="3">Source: 0x089000C4 [ 0043001B divu $v0, $v1]</TD></TR><HR/>
<TR><TD port="1_3" align="left">0xA3FB08D2( 2)</TD><VR/>
<TD port="2_3" align="right">____________________________E98B</TD><VR/>
<TD port="3_3" align="left">mov ebp, ecx </TD></TR><HR/>
<TR><TD port="e" colspan="3"> </TD></TR></TABLE>>];
The details concerning HTML-like labels can be found at http://www.graphviz.org/content/node-shapes#html [^]
Thanks for your quick answer.
Indeed, there were two issues at this time. A bug in the CFG builder was creating some weird nodes without record shape but even fixing it, I was still unable open the resulting .gv file. So, at the end, I created each basic block as a node xxx instead of a subgraph cluster_xxx and put the basic block label inside the field b. No issue since then.
Your suggestion to use HTML-like labels is something I wanted to try but I didn't have a clear idea how to use it. It may worth while trying to do so.
Thank you very much. I appreciate your effort to help me.
Attached is a new file 'cfg_sb_0xA3FB0840-201408166.gv' archived as a .7z file. It's pretty big and GVEdit always crashes while opening it. Otherwise, is there another way to check the validity of a .gv file to be sure there is no ill-formed descriptions which might explain the crash?
Okay, that's a problem. What's happening is that when you open a file in gvedit, it automatically creates a layout in PNG to display. In this case, the image would be larger than the size supported by the renderer (libcairo), which causes the crash. I will have to look into if we can expand the limit and also handle the error more gracefully. (I don't have the problem on Linux or OSX.)
To answer your second question, the Graphviz tools are really designed for a command-line interface like the dos shell. If you open a dos shell and have the Graphviz bin in your PATH variable, you can just run
dot -Tpng cfg_sb_0xA3FB0840.gv -o out.png
to get your output, or see if an error occurs.
In general, if your output image is going to be large, it is helpful to use the size parameter to limit the size of the output image. The problem with this for bitmap images is that you won't be able to read the details and bitmap images don't enlarge well. (By the way, Graphviz comes with a collection of renderers for different output formats, including one that allows you to produce a PNG image of your file. The problem then is that the usual Windows tools for viewing bitmaps complain that the image is too big.)
So, for large image sizes, it is best to use a vector format like SVG or PDF. You can then use a variety of viewers including most browsers, to look at the output, panning and zooming to your heart's content.
Indeed, I was using gvedit.exe to generate a .pdf from a .gv file. And just before you answered me how to proceed without gvedit.exe, I tried this direct way "dot -Tpdf cfg_sb_0xA3FB0840.gv -o cfg_sb_0xA3FB0840.pdf" but I just obtained a blank page as a result (I also tried with a working .gv file to be sure I obtained a working .pdf file as a test).
After your suggestion to use a vector format like SVG or PDF, I tried "dot -Tsvg cfg_sb_0xA3FB0840.gv -o cfg_sb_0xA3FB0840.svg" and I finally obtain an output.
So to sum up, command-line dot renders well with SVG, crashes with PNG, renders a blank page with PDF.
Thank you very much.
|Please post your pdf output to this bug report. And how are you viewing it? If you just double-click on it, that probably starts acrobat, which shows a blank page. If you open it in Chrome, or some other viewer, it looks fine. At least, when I use dot -Tpdf on your file (version 2.38), that's what I get.|
edited on: 2014-08-17 19:03
Attached is the .pdf file (sb_0xA3FB0840.gv-20140818.pdf). Opening with Adobe Reader it shows a blank page. Opening with Chromium, it indeed shows something fine. The main reason I use Adobe is because you can use the "grab" cursor to move the page which makes life easier, especially with huge page.
|2014-08-08 20:45||hlide||New Issue|
|2014-08-08 20:45||hlide||File Added: cfg_sb_0xA3FB0720.7z|
|2014-08-08 20:59||hlide||File Added: cfg_sb_0xA3FB0800 - Incomplete.png|
|2014-08-11 15:09||erg||Note Added: 0000791|
|2014-08-11 15:09||erg||Assigned To||=> erg|
|2014-08-11 15:09||erg||Status||new => assigned|
|2014-08-11 16:21||hlide||Note Added: 0000792|
|2014-08-16 06:49||hlide||File Added: cfg_sb_0xA3FB0840-201408166.7z|
|2014-08-16 06:56||hlide||Note Added: 0000797|
|2014-08-16 14:26||erg||Note Added: 0000798|
|2014-08-16 19:15||hlide||Note Added: 0000799|
|2014-08-17 12:31||erg||Note Added: 0000800|
|2014-08-17 18:53||hlide||File Added: sb_0xA3FB0840.gv-20140818.pdf|
|2014-08-17 18:59||hlide||Note Added: 0000801|
|2014-08-17 19:03||hlide||Note Edited: 0000801||View Revisions|
|MantisBT 1.2.5[^] Copyright © 2000 - 2011 MantisBT Group|