Graphviz Issue Tracker
Mantis Bug Tracker

View Issue Details Jump to Notes ] Issue History ] Print ]
IDProjectCategoryView StatusDate SubmittedLast Update
0002478graphvizGVeditpublic2014-08-08 20:452014-08-17 18:59
Assigned Toerg 
PlatformOSWindowsOS Version8.1
Summary0002478: Gvedit crashes when trying to open my gv script
DescriptionI'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 Reproducejust open "cfg_sb_0xA3FB0800.gv".
TagsNo tags attached.
Attached Files7z file icon cfg_sb_0xA3FB0720.7z (Attachment missing)
png file icon cfg_sb_0xA3FB0800 - Incomplete.png (Attachment missing)
7z file icon cfg_sb_0xA3FB0840-201408166.7z (Attachment missing)
pdf file icon sb_0xA3FB0840.gv-20140818.pdf (Attachment missing)

- Relationships

-  Notes
User avatar (0000791)
erg (administrator)
2014-08-11 15:09

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 [^]
User avatar (0000792)
hlide (reporter)
2014-08-11 16:21

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.
User avatar (0000797)
hlide (reporter)
2014-08-16 06:56


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?
User avatar (0000798)
erg (administrator)
2014-08-16 14:26

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.
User avatar (0000799)
hlide (reporter)
2014-08-16 19:15

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.
User avatar (0000800)
erg (administrator)
2014-08-17 12:31

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.
User avatar (0000801)
hlide (reporter)
2014-08-17 18:59
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.

- Issue History
Date Modified Username Field Change
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
Powered by Mantis Bugtracker