Graphviz (dot) crashes when inputting multiple diagrams from STDIN

Hello, I would like to report a bug in dot and perhaps offer assistance. I am testing this on the latest March 16th development snapshot, but the stable version did not work as well. Unfortunately I am not familiar enough with the codebase to know what is going on .. but from I was able to rule out is the cleanup procedures in dot.c - commenting them out does not fix the crash. Also I had a real world example with HTML labels .. they caused a lot of problems in a second input as well. Would be cool to fix it as it would allow running dot as a worker for an FastCGI application for example. Currently the fontconfig initialization in pango layout really takes ages to start.


# echo -e "digraph {} \n digraph{}") valgrind dot -T svg
==20541== Invalid read of size 8
==20541== at 0x4EB3B90: layerPagePrefix (emit.c:183)
==20541== by 0x4EB3CB2: getObjId (emit.c:205)
==20541== by 0x4EB400E: initObjMapData (emit.c:265)
==20541== by 0x4EC033A: emit_begin_graph (emit.c:3343)
==20541== by 0x4EC0AD2: emit_graph (emit.c:3468)
==20541== by 0x4EC2B10: gvRenderJobs (emit.c:4094)
==20541== by 0x4011CE: main (dot.c:216)
==20541== Address 0x10 is not stack'd, malloc'd or (recently) free'd
==20541==
==20541==
==20541== Process terminating with default action of signal 11 (SIGSEGV)
==20541== Access not within mapped region at address 0x10
==20541== at 0x4EB3B90: layerPagePrefix (emit.c:183)
==20541== by 0x4EB3CB2: getObjId (emit.c:205)
==20541== by 0x4EB400E: initObjMapData (emit.c:265)
==20541== by 0x4EC033A: emit_begin_graph (emit.c:3343)
==20541== by 0x4EC0AD2: emit_graph (emit.c:3468)
==20541== by 0x4EC2B10: gvRenderJobs (emit.c:4094)
==20541== by 0x4011CE: main (dot.c:216)

I am running openSUSE 12.3

I am running openSUSE 12.3 and I compile graphviz manually. Plase make sure it is run with -Tsvg, otherwise the bug does not occur. I would happily post a bug report but perhaps it is my fault somehow. Do you confirm that with -Tsvg it works for you with multiple diagrams?

There was indeed a bug. It

There was indeed a bug. It has now been fixed. The changes will appear in tomorrow's (28 March 2013) packages.

Supposedly yet another bug

Thanks, one bug fixed, more to go though. ;) I think I found another problem in the same context...

> (for i in {1..2};do echo "graph { elem[label=<a>,shape=record] }";done) | valgrind dot -Tsvg
<first proper svg output>
==2461== Invalid read of size 1
==2461==    at 0x4E6E6E3: free_html_label (htmltable.c:807)
==2461==    by 0x4E7C37D: free_label (labels.c:216)
==2461==    by 0xD6B9D69: dot_cleanup_node (dotinit.c:111)
==2461==    by 0xD6BA32A: dot_cleanup (dotinit.c:213)
==2461==    by 0x4E562A3: gvFreeLayout (gvlayout.c:116)
==2461==    by 0x401083: main (dot.c:212)
==2461==  Address 0x8 is not stack'd, malloc'd or (recently) free'd
==2461== Process terminating with default action of signal 11 (SIGSEGV)
==2461==  Access not within mapped region at address 0x8
==2461==    at 0x4E6E6E3: free_html_label (htmltable.c:807)
==2461==    by 0x4E7C37D: free_label (labels.c:216)
==2461==    by 0xD6B9D69: dot_cleanup_node (dotinit.c:111)
==2461==    by 0xD6BA32A: dot_cleanup (dotinit.c:213)
==2461==    by 0x4E562A3: gvFreeLayout (gvlayout.c:116)
==2461==    by 0x401083: main (dot.c:212)

Segmentation fault

This has now been fixed. Note

This has now been fixed. Note that your usage, though legal, is atypical. Normally, one doesn't usage HTML-like strings with record shapes.

Thanks for pointing out these bugs.

Memory leaks

The latest fix worked but it is me who should be thanking you for maintaining this awesome software. If you could still bare with me, it seems that graphiz and its html labels feature seems to be leeking quite a lot of memory. I am pasting some of the more obvious leaks. Please tell me if those are not obvious enough, I could do more debugging. I paste results of running the same graph 1000 times.

==24324== 936 bytes in 9 blocks are definitely lost in loss record 423 of 485
==24324==    at 0x4C2C27B: malloc (in /usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so)
==24324==    by 0x4E68E1C: gmalloc (memory.c:49)
==24324==    by 0x4E68E7C: zmalloc (memory.c:27)
==24324==    by 0x4E6AB2A: appendFLineList (htmlparse.y:213)
==24324==    by 0x4E6B48B: htmlparse (htmlparse.y:463)
==24324==    by 0x4E6B8E1: parseHTML (htmlparse.y:610)
==24324==    by 0x4E6FB3E: make_html_label (htmltable.c:2008)
==24324==    by 0x4E7C1AA: make_label (labels.c:148)
==24324==    by 0x4E80E50: parse_reclbl (shapes.c:3180)
==24324==    by 0x4E814F5: record_init (shapes.c:3420)
==24324==    by 0xD6B9F18: dot_init_node_edge (dotinit.c:40)
==24324==    by 0xD6BA491: dot_layout (dotinit.c:369)
==24324== 
==24324== 1,560 bytes in 50 blocks are definitely lost in loss record 440 of 485
==24324==    at 0x4C2C27B: malloc (in /usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so)
==24324==    by 0x76D6EE1: strdup (in /lib64/libc-2.17.so)
==24324==    by 0x4E80E2E: parse_reclbl (shapes.c:3180)
==24324==    by 0x4E814F5: record_init (shapes.c:3420)
==24324==    by 0xD6B9F18: dot_init_node_edge (dotinit.c:40)
==24324==    by 0xD6BA491: dot_layout (dotinit.c:369)
==24324==    by 0x4E5620A: gvLayoutJobs (gvlayout.c:90)
==24324==    by 0x40109E: main (dot.c:215)
==24324== 
==24324== 4,680 bytes in 45 blocks are definitely lost in loss record 467 of 485
==24324==    at 0x4C2C27B: malloc (in /usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so)
==24324==    by 0x4E68E1C: gmalloc (memory.c:49)
==24324==    by 0x4E68E7C: zmalloc (memory.c:27)
==24324==    by 0x4E6AB2A: appendFLineList (htmlparse.y:213)
==24324==    by 0x4E6AC9E: mkText (htmlparse.y:236)
==24324==    by 0x4E6B4A7: htmlparse (htmlparse.y:455)
==24324==    by 0x4E6B8E1: parseHTML (htmlparse.y:610)
==24324==    by 0x4E6FB3E: make_html_label (htmltable.c:2008)
==24324==    by 0x4E7C1AA: make_label (labels.c:148)
==24324==    by 0x4E80E50: parse_reclbl (shapes.c:3180)
==24324==    by 0x4E814F5: record_init (shapes.c:3420)
==24324==    by 0xD6B9F18: dot_init_node_edge (dotinit.c:40)
==24324== 
==24324== 9,360 bytes in 90 blocks are definitely lost in loss record 476 of 485
==24324==    at 0x4C2C27B: malloc (in /usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so)
==24324==    by 0x4E68E1C: gmalloc (memory.c:49)
==24324==    by 0x4E68E7C: zmalloc (memory.c:27)
==24324==    by 0x4E6AB2A: appendFLineList (htmlparse.y:213)
==24324==    by 0x4E6AC9E: mkText (htmlparse.y:236)
==24324==    by 0x4E6B4A7: htmlparse (htmlparse.y:455)
==24324==    by 0x4E6B8E1: parseHTML (htmlparse.y:610)
==24324==    by 0x4E6FB3E: make_html_label (htmltable.c:2008)
==24324==    by 0x4E7C1AA: make_label (labels.c:148)
==24324==    by 0x4E8AE95: common_init_edge (utils.c:807)
==24324==    by 0xD6BA070: dot_init_node_edge (dotinit.c:57)
==24324==    by 0xD6BA491: dot_layout (dotinit.c:369)
==24324== 
==24324== 10,296 bytes in 99 blocks are definitely lost in loss record 477 of 485
==24324==    at 0x4C2C27B: malloc (in /usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so)
==24324==    by 0x4E68E1C: gmalloc (memory.c:49)
==24324==    by 0x4E68E7C: zmalloc (memory.c:27)
==24324==    by 0x4E6AB2A: appendFLineList (htmlparse.y:213)
==24324==    by 0x4E6AC9E: mkText (htmlparse.y:236)
==24324==    by 0x4E6B4A7: htmlparse (htmlparse.y:455)
==24324==    by 0x4E6B8E1: parseHTML (htmlparse.y:610)
==24324==    by 0x4E6FB3E: make_html_label (htmltable.c:2008)
==24324==    by 0x4E7C1AA: make_label (labels.c:148)
==24324==    by 0x4E8A986: common_init_node (utils.c:707)
==24324==    by 0xD6B9F18: dot_init_node_edge (dotinit.c:40)
==24324==    by 0xD6BA491: dot_layout (dotinit.c:369)
==24324== 
==24324== 18,826 (200 direct, 18,626 indirect) bytes in 5 blocks are definitely lost in loss record 483 of 485
==24324==    at 0x4C2C27B: malloc (in /usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so)
==24324==    by 0x4E68E1C: gmalloc (memory.c:49)
==24324==    by 0x4E58AD7: gvplugin_install (gvplugin.c:116)
==24324==    by 0x4E5AC6A: gvconfig (gvconfig.c:201)
==24324==    by 0x4E70564: dotneato_args_initialize (input.c:267)
==24324==    by 0x4E68AFF: gvParseArgs (args.c:282)
==24324==    by 0x400E7D: main (dot.c:184)

You should be able to make

You should be able to make these all go away by using ordinary strings for labels with shape=record, rather than HTML-like strings. Alternatively, we deprecate the use of shape=record, as HTML-like labels provide much more general features.

Please submit a bug report at

Please submit a bug report at http://www.graphviz.org/content/graphviz-issue-tracker. In particular, it would help to know what OS you are running. You also might want to check if it makes a difference to put the multiple graphs in a single file and cat that file into dot through a pipe.

I assume your input line should have a '|' rather than a ')'. Certainly, the graphviz layout engines were built to act as servers, accepting a stream of input graphs. This indeed works fine on the machines I have access to.

Recent comments