Graphviz Issue Tracker
Mantis Bug Tracker

View Issue Details Jump to Notes ] Issue History ] Print ]
IDProjectCategoryView StatusDate SubmittedLast Update
0002133graphvizDotpublic2011-08-27 17:072011-09-01 22:12
Reportermeconlen 
Assigned To 
PrioritynormalSeveritymajorReproducibilityhave not tried
StatusnewResolutionopen 
PlatformMacintoshOSOS XOS Version10.6.8
Summary0002133: segfault in gvplugin_quartz_LTX_library or gvplugin_core_LTX_library
DescriptionI get a segfault at the following point

(gdb) run -v test.dot -Tpng -o test.dot
The program being debugged has been started already.
Start it from the beginning? (y or n) yStarting program: /usr/local/bin/dot -v test.dot -Tpng -o test.dot
dot - graphviz version 2.28.0 (20110509.1543)
libdir = "/usr/local/lib/graphviz"
Activated plugin library: libgvplugin_quartz.6.dylib
Using textlayout: textlayout:quartz
Using render: quartz:quartz
Using device: png:quartz:quartz
Activated plugin library: libgvplugin_dot_layout.6.dylib
Using layout: dot:dot_layout
The plugin configuration file:
        /usr/local/lib/graphviz/config6
                was successfully loaded.
    render : dot fig map ps quartz svg tk vml xdot
    layout : dot
    textlayout : textlayout
    device : bmp canon cgimage cmap cmapx cmapx_np dot eps exr fig gif gv imap imap_np ismap jp2 jpe jpeg jpg pct pdf pict plain plain-ext png ps
ps2 psd sgi svg svgz tga tif tiff tk vml vmlz xdot
    loadimage : (lib) bmp eps gif jpe jpeg jpg pdf png ps svg
fontname: unable to resolve "Times-Roman"
network simplex: 1026 nodes 2048 edges maxiter=2147483647 balance=1
network simplex: 1026 nodes 2048 edges 0 iter 0.00 sec

Program received signal EXC_BAD_ACCESS, Could not access memory.
Reason: KERN_PROTECTION_FAILURE at address: 0x00007fff5f3fffe8
0x000000010011fd3b in gvplugin_quartz_LTX_library ()
Steps To ReproduceThe .dot included listed below runs fine; however if you uncomment the one commented node near the end dot segfaults pretty quickly. If you change either node identifier (from or to) to any other node, new or existing, it runs fine. If you simply move the line it still segfaults. I verified there are no stray characters in the text that you can't see.

Additional InformationI haven't tested on other platforms yet, but I'm installing graphviz on a FreeBSD 8 machine to test shortly.
TagsNo tags attached.
AUXILLARY-FILES
DATE-FIXED
FIX-COMMENT
FORMER-ID
INPUT-FILE
OUTPUT-FILE
STATUS-COMMENT
VERSIONdot - graphviz version 2.28.0 (20110509.1543)
Attached Filesdot file icon test.dot [^] (90,290 bytes) 2011-08-27 17:07

- Relationships

-  Notes
User avatar (0000057)
meconlen (reporter)
2011-08-27 18:06

I tested this same file on

FreeBSD stewie 8.0-RELEASE FreeBSD 8.0-RELEASE #0: Sat Nov 21 15:02:08 UTC 2009 [email protected]:/usr/obj/usr/src/sys/GENERIC amd64

and received segfault from

(gdb) run -v test.dot -Tpng -o test.png
Starting program: /usr/local/bin/dot -v test.dot -Tpng -o test.png
(no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)...[New LWP 100514]
[New Thread 801302540 (LWP 100514)]
dot - graphviz version 2.28.0 (20110827.2149)
libdir = "/usr/local/lib/graphviz"
Activated plugin library: libgvplugin_pango.so.6
Using textlayout: textlayout:cairo
Using render: cairo:cairo
Using device: png:cairo:cairo
(no debugging symbols found)...Activated plugin library: libgvplugin_dot_layout.so.6
Using layout: dot:dot_layout
The plugin configuration file:
        /usr/local/lib/graphviz/config6
                was successfully loaded.
    render : cairo dot fig gd map ps svg tk vml vrml xdot
    layout : circo dot fdp neato nop nop1 nop2 osage patchwork sfdp twopi
    textlayout : textlayout
    device : canon cmap cmapx cmapx_np dot eps fig gd gd2 gif gv imap imap_np ismap jpe jpeg jpg pdf plain plain-ext png ps ps2 svg svgz tk vml vmlz vrml wbmp x11 xdot xlib
    loadimage : (lib) eps gd gd2 gif jpe jpeg jpg png ps svg
(no debugging symbols found)...fontname: "Times-Roman" resolved to: (ps:pango Bitstream Vera Serif, REGULAR) (PangoCairoFcFont) "Bitstream Vera Serif, Roman" /usr/local/lib/X11/fonts/bitstream-vera/VeraSe.ttf
network simplex: 1026 nodes 2048 edges maxiter=2147483647 balance=1
network simplex: 1026 nodes 2048 edges 0 iter 0.00 sec

Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 801302540 (LWP 100514)]
0x000000080360c8ff in search_component ()
   from /usr/local/lib/graphviz/libgvplugin_dot_layout.so.6
(gdb)
User avatar (0000058)
meconlen (reporter)
2011-08-27 18:07

On FreeBSD the file with the problem line commented out also sigsegv
User avatar (0000059)
meconlen (reporter)
2011-08-27 18:31

On FreeBSD I get the following from gdb

Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 801302540 (LWP 100186)]
0x000000080360d858 in search_component (g=Error accessing memory address 0x7fffffbfffc8: Bad address.
) at decomp.c:64
64 {


unless I comment a very strange list (non-contiguous) entries

# "1111101000" -> "1111010001" [label ="1"];
# "1111101010" -> "1111010101" [label ="1"];
# "1111101011" -> "1111010110" [label ="0"];
# "1111101011" -> "1111010111" [label ="1"];
# "1111101100" -> "1111011000" [label ="0"];
# "1111101101" -> "1111011010" [label ="0"];
# "1111101101" -> "1111011011" [label ="1"];
# "1111101110" -> "1111011100" [label ="0"];
# "1111101110" -> "1111011101" [label ="1"];
# "1111101111" -> "1111011110" [label ="0"];
# "1111101111" -> "1111011111" [label ="1"];
# "1111110000" -> "1111100000" [label ="0"];
# "1111110001" -> "1111100010" [label ="0"];
# "1111110001" -> "1111100011" [label ="1"];
# "1111110010" -> "1111100100" [label ="0"];
# "1111110010" -> "1111100101" [label ="1"];
# "1111110011" -> "1111100110" [label ="0"];
# "1111110011" -> "1111100111" [label ="1"];
User avatar (0000060)
meconlen (reporter)
2011-08-27 18:32

(gdb) backtrace
#0 0x000000080360d858 in search_component (g=Error accessing memory address 0x7fffffbfffc8: Bad address.
) at decomp.c:64
0000001 0x000000080360d956 in search_component (g=0x801302700, n=0x8158ee200)
    at decomp.c:82
0000002 0x000000080360d956 in search_component (g=0x801302700, n=0x8158ee400)
    at decomp.c:82
0000003 0x000000080360d956 in search_component (g=0x801302700, n=0x8158ee600)
    at decomp.c:82
0000004 0x000000080360d956 in search_component (g=0x801302700, n=0x8158ee800)
    at decomp.c:82
0000005 0x000000080360d956 in search_component (g=0x801302700, n=0x8158eea00)
    at decomp.c:82
0000006 0x000000080360d956 in search_component (g=0x801302700, n=0x8158eec00)
    at decomp.c:82
0000007 0x000000080360d956 in search_component (g=0x801302700, n=0x8158eee00)
    at decomp.c:82
0000008 0x000000080360d956 in search_component (g=0x801302700, n=0x8158ef000)
    at decomp.c:82
0000009 0x000000080360d956 in search_component (g=0x801302700, n=0x8158ef200)
    at decomp.c:82
0000010 0x000000080360d956 in search_component (g=0x801302700, n=0x8158ef400)
    at decomp.c:82
#11 0x000000080360d956 in search_component (g=0x801302700, n=0x8158ef600)
    at decomp.c:82
---Type <return> to continue, or q <return> to quit---
User avatar (0000063)
erg (administrator)
2011-08-31 11:01

Clearly, the stack is overflowing from the recursion in search_component. Unfortunately, it appears to be an optimizer bug. The problem goes away when -O is removed from the build for decomp.c.
User avatar (0000065)
meconlen (reporter)
2011-09-01 10:27

Are we sure? I've often found that something compiles and runs without segfault, and even runs properly, but fails with compiler optimizations because the optimization revealed a bug which was masked by not having any optimization. In particular I recall a line such as

printf("d = %d\n");

which ran fine and even found the variable I meant to put there.

the catch is verifying the output of this graph will be a little... ...difficult.
User avatar (0000069)
erg (administrator)
2011-09-01 22:12

Well, we are still looking into it since we would like to report it to the gcc people if we can provide a small example. But the stack is definitely overflowing in the recursion; the code is small and simple and hasn't changed for 20 years; and when I look at the head and tail of the edge, both are fine, yet neither is
passed down as n in recursion as the code specifies.

- Issue History
Date Modified Username Field Change
2011-08-27 17:07 meconlen New Issue
2011-08-27 17:07 meconlen File Added: test.dot
2011-08-27 18:06 meconlen Note Added: 0000057
2011-08-27 18:07 meconlen Note Added: 0000058
2011-08-27 18:31 meconlen Note Added: 0000059
2011-08-27 18:32 meconlen Note Added: 0000060
2011-08-31 11:01 erg Note Added: 0000063
2011-09-01 10:27 meconlen Note Added: 0000065
2011-09-01 22:12 erg Note Added: 0000069


MantisBT 1.2.5[^]
Copyright © 2000 - 2011 MantisBT Group
Powered by Mantis Bugtracker