Graphviz Issue Tracker
Mantis Bug Tracker

View Issue Details Jump to Notes ] Issue History ] Print ]
IDProjectCategoryView StatusDate SubmittedLast Update
0002554graphvizDotpublic2015-06-15 16:492015-06-16 11:01
Reportersdutta 
Assigned To 
PrioritynormalSeveritymajorReproducibilityalways
StatusnewResolutionopen 
PlatformLinux64OSDebianOS Version3.10
Summary0002554: Dot seg-faults during rank computation...
DescriptionThe attached graph (dot file) has only ~4000 nodes and ~6000 edges. Dot seg-faults during rank computation. I have tried various "iteration limit" option but has not been able to avoid the seg-fault.

Any response to resolve the seg-fault will be helpful - be it regarding executable "options" or identifying the pattern in the "input" graph that I can modify. Thanks.
Steps To Reproduce$ dot -v -Tplain -o try.plain try.dot
Additional InformationUsed the following options so far but of no help.
1. nslimit
2. nslimit1
3. remincross
4. mclimit
TagsNo tags attached.
AUXILLARY-FILES
DATE-FIXED
FIX-COMMENT
FORMER-ID
INPUT-FILE
OUTPUT-FILE
STATUS-COMMENT
VERSION
Attached Filesdot file icon try.dot (Attachment missing)

- Relationships

-  Notes
User avatar (0000950)
north (administrator)
2015-06-16 09:07

I think due to a very very long chain in this graph we are somehow blowing out of stack space. ulimit -a says we have 8192K of stack. We could rewrite our code to use the heap. Ha ha is it really 2015? For now just increase ulimit -s a lot and see what happens.

(lldb) run -v try.dot -o output.dot
Process 85829 launched: '/Users/north/bin/dot' (x86_64)
dot - graphviz version 2.39. ()
libdir = "/Users/north/lib/graphviz"
Activated plugin library: libgvplugin_dot_layout.6.dylib
Using layout: dot:dot_layout
Activated plugin library: libgvplugin_core.6.dylib
Using render: dot:core
Using device: dot:dot:core
The plugin configuration file:
    /Users/north/lib/graphviz/config6
        was successfully loaded.
    render : cairo dot fig gd lasi map pic pov ps quartz svg tk vml vrml xdot
    layout : circo dot fdp neato nop nop1 nop2 osage patchwork sfdp twopi
    textlayout : textlayout
    device : bmp canon cgimage cmap cmapx cmapx_np dot eps exr fig gd gd2 gif gtk gv icns ico imap imap_np ismap jp2 jpe jpeg jpg pct pdf pic pict plain plain-ext png pov ps ps2 psd sgi svg svgz tga tif tiff tk vml vmlz vrml wbmp x11 xdot xdot1.2 xdot1.4 xlib
    loadimage : (lib) bmp eps gd gd2 gif ico jpe jpeg jpg pdf png ps svg
pack info:
  mode undefined
  size 0
  flags 0
  margin 8
pack info:
  mode node
  size 0
  flags 0
fontname: "Times-Roman" resolved to: (ps:pango Times, REGULAR) (PangoCairoCoreTextFont) "Times Medium"
network simplex: 4123 nodes 6180 edges maxiter=103075 balance=1
network simplex: 4123 nodes 6180 edges 1 iter 0.02 sec
Maxrank = 4117, minrank = 0
mincross: pass 0 iter 0 trying 0 cur_cross 1 best_cross 1
mincross: pass 0 iter 1 trying 1 cur_cross 2057 best_cross 1
mincross: pass 1 iter 0 trying 0 cur_cross 4113 best_cross 1
mincross: pass 1 iter 1 trying 1 cur_cross 6138 best_cross 1
mincross: pass 2 iter 0 trying 0 cur_cross 1 best_cross 1
mincross: pass 2 iter 1 trying 1 cur_cross 2057 best_cross 1
mincross n3: 1 crossings, 776.25 secs.
network simplex: 8478968 nodes 12716391 edges maxiter=103075 balance=2
Process 85829 stopped
* thread 0000001: tid = 0x2d094a, 0x0000000100038508 libgvc.6.dylib`treesearch(v=0x0000000212a948e0) + 8 at ns.c:263, queue = 'com.apple.main-thread', stop reason = EXC_BAD_ACCESS (code=2, address=0x7fff5f3ffff8)
    frame #0: 0x0000000100038508 libgvc.6.dylib`treesearch(v=0x0000000212a948e0) + 8 at ns.c:263
   260 }
   261
   262 static int treesearch(node_t * v)
-> 263 {
   264 int i;
   265 edge_t *e;
   266
(lldb) tb
No breakpoints currently set.
(lldb) bt
* thread 0000001: tid = 0x2d094a, 0x0000000100038508 libgvc.6.dylib`treesearch(v=0x0000000212a948e0) + 8 at ns.c:263, queue = 'com.apple.main-thread', stop reason = EXC_BAD_ACCESS (code=2, address=0x7fff5f3ffff8)
  * frame #0: 0x0000000100038508 libgvc.6.dylib`treesearch(v=0x0000000212a948e0) + 8 at ns.c:263
    frame 0000001: 0x00000001000385c3 libgvc.6.dylib`treesearch(v=0x0000000212eb37d0) + 195 at ns.c:270
    frame 0000002: 0x00000001000385c3 libgvc.6.dylib`treesearch(v=0x000000021319a9d0) + 195 at ns.c:270
    frame 0000003: 0x00000001000385c3 libgvc.6.dylib`treesearch(v=0x00000002134b0790) + 195 at ns.c:270
    frame 0000004: 0x00000001000385c3 libgvc.6.dylib`treesearch(v=0x0000000213b3e0b0) + 195 at ns.c:270
    frame 0000005: 0x00000001000385c3 libgvc.6.dylib`treesearch(v=0x0000000213f38a10) + 195 at ns.c:270
    frame 0000006: 0x00000001000385c3 libgvc.6.dylib`treesearch(v=0x0000000213a5e350) + 195 at ns.c:270
    frame 0000007: 0x00000001000385c3 libgvc.6.dylib`treesearch(v=0x00000002146a06b0) + 195 at ns.c:270
    frame 0000008: 0x00000001000385c3 libgvc.6.dylib`treesearch(v=0x0000000214c42680) + 195 at ns.c:270
    frame 0000009: 0x00000001000385c3 libgvc.6.dylib`treesearch(v=0x0000000215059330) + 195 at ns.c:270
    frame 0000010: 0x00000001000385c3 libgvc.6.dylib`treesearch(v=0x0000000214e34e50) + 195 at ns.c:270
User avatar (0000951)
sdutta (reporter)
2015-06-16 11:01

Along with the stack size, the runtime is unusually large. Is there a way to detect this pattern, and terminate earlier with the usual bad layout without getting stuck in the stack?

- Issue History
Date Modified Username Field Change
2015-06-15 16:49 sdutta New Issue
2015-06-15 16:49 sdutta File Added: try.dot
2015-06-16 09:07 north Note Added: 0000950
2015-06-16 11:01 sdutta Note Added: 0000951


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