Graphviz Issue Tracker
 Anonymous | Login 2017-11-21 05:11 EST
 Main | My View | View Issues | Change Log | Roadmap | My Account

View Issue Details  Print ]
IDProjectCategoryView StatusDate SubmittedLast Update
0002506graphvizDotpublic2015-01-15 07:412015-01-21 11:04
Reportercmot
Assigned To
PrioritynormalSeverityimportantReproducibilitysometimes
StatusnewResolutionopen
Summary0002506: Edges sometimes start WITHIN a node, not at the node's border
DescriptionIn our Eclipse tool (KIELER: http://rtsys.informatik.uni-kiel.de/confluence/display/KIELER/Home [^]) we have a process open that talks using stdin/stdout with dot.exe in order to do (hierarchical) layouts for state charts diagrams.

When performing multiple layouts, sporadically single ones are corrupt in the sense that some edges start NOT at node borders (but within the node).

We can reproduce this in our tool. The situation SEEMS to be better, if we have a new Java process for talking to dot.exe for EACH layout invocation. 1. This REALLY slows down layout, 2. we are not confident that this workaround really SOLVES the problem, because we not fully understand the problem.

We tried one quite simple example in a GraphViz web service: http://graphviz-dev.appspot.com/ [^]

The example is as follows:

digraph {
graph [aspect="1.22,1",
bb="0,138,125.5,0",
nodesep=0.6041667,
rankdir=TB,
ranksep=0.6041667,
splines=spline
];
node [fixedsize=true,
label="\N",
shape=box
];
edge [dir=none];
node1 [height=0.47222,
width=0.63889];
node2 [height=0.55556,
width=0.70833];
node1 -> node2 [comment=edge1,
fontname=Arial,
fontsize=18,
label=" A / O = true",
lp="75.5,66"];
}

When doing multiple consecutive layouts (can be triggered simply by adding space characters to modify'' the dot file), eventually there are corrupt layouts, just like the corrupt layouts we get in our Eclipse tool. We PRESUME that the online web service is programmed also with just ONE open process talking to dot.exe like our setup - but this is just an hypothesis.

In the attached zip you find these screen shots and also the dot test file.
Steps To ReproduceReproduce:

1. go to the web service: http://graphviz-dev.appspot.com/ [^]

2. enter the dot file (from attachment or description)

3. make fake-changes to it by adding space characters and carefully inspect the output image

4. eventually you should be able to see corrupt graph layouts
TagsNo tags attached.
AUXILLARY-FILES
DATE-FIXED
FIX-COMMENT
FORMER-ID
INPUT-FILE
OUTPUT-FILE
STATUS-COMMENT
VERSIONgraphviz version 2.38.0 (20140413.2041)
Attached Files ticket.zip (Attachment missing)
 Notes erg (administrator) 2015-01-15 15:50 I am having trouble getting the site to work at all. Most times when I go to the given site, I just get the message [1] 15:32:30 - failure to convert script. Even if I get a good initial drawing and then paste in the graph given in the bug report, I then get a failure to convert script message. Are there dependencies on the browser or system I should be running on? I tried using IE and Chrome on Windows, and Chrome, Firefox and Safari on Macs, all with the same result. As for trying to track down the problem, in what format is Graphviz returning the graph layout information? If in text format such as xdot or svg, can you capture and provide sequence of the outputs? What do you send to the Graphviz process? Do you send over the graph after each keystroke? Have you seen any other oddities besides the edge not touching the node boundary? How are you setting up the pipeline? Thanks. cmot (reporter) 2015-01-16 05:18 edited on: 2015-01-16 05:19 Thanks for your answer. 1. First let me make clear that this site is NOT our site. It is just a website that we found with Google. But the issue that we have in our KIELER tool with GraphViz can ALSO be inspected at this site. Because we thought it might be easier to check/reproduce this bug with this website, we liked it (instead of trying to give longer instructions how to reproduce it with our KIELER tool). 2. If you have problems accessing this site, maybe it's because of a firewall restriction? As far we could see this site is using AJAX for communication. 3. The message "failure to convert script" has no impact on this bug. It occurs also to us but the reported bug appears with and even without this message. We think you can ignore this message (which could just mean you have been TOO quickly triggering two consecutive GraphViz calls or something like that). However, at least to our knowledge, THIS is NOT causing the reported bug. 4. We tested it with Window and were able to reproduce the bug with Firefox and Chrome. To our knowledge there are NO dependencies to the system or browser. If you get the error message, just add a space character somewhere after a while (not too quickly). This should trigger another fresh call to GraphViz (on their server). 5. Be aware that the reported bug sometimes tarries ... so you have to give it enough tries (sometimes 20-30) until it appears. At other times it may appear already after 2 or 3 tries. Its non-deterministic. 6. Formats 6.1. We send the following format TO GraphViz: digraph {     graph [aspect="1.22,1",         bb="0,138,125.5,0",         nodesep=0.6041667,         rankdir=TB,         ranksep=0.6041667,         splines=spline     ];     node [fixedsize=true,         label="\N",         shape=box     ];     edge [dir=none];     node1 [height=0.47222,         width=0.63889];     node2 [height=0.55556,         width=0.70833];     node1 -> node2 [comment=edge1,         fontname=Arial,         fontsize=18,         label=" A / O = true",         lp="75.5,66"]; } 6.2. We get the following annotated format FROM GraphViz: digraph {     graph [aspect="1.22,1",         bb="0,138,125.5,0",         nodesep=0.6041667,         rankdir=TB,         ranksep=0.6041667,         splines=spline     ];     node [fixedsize=true,         label="\N",         shape=box     ];     edge [dir=none];     node1 [height=0.47222,         pos="25.5,7000",         width=0.63889];     node2 [height=0.55556,         pos="25.5,118",         width=0.70833];     node1 -> node2 [comment=edge1,         fontname=Arial,         fontsize=18,         label=" A / O = true",         lp="75.5,66",         pos="25.5,18.072 25.5,20.215 25.5,69.846 25.5,97.978"]; } 6.3 Arguments when we create the GraphViz process: [C:\Program Files (x86)\Graphviz2.38\bin\dot.exe, -q, -y, -Kdot] 6.4. Q: Do you send over the graph after each keystroke? A: Again this is not our website but it seems that the website is updating/send the graph after some timeout after the last modification yes 6.5. Q: Have you seen any other oddities besides the edge not touching the node boundary? A: No, this is our only but still very annoying problem. 6.6. Q: How are you setting up the pipeline? A: This is the code (simplified) String[] args = {"C:\\Program Files (x86)\\Graphviz2.38\\bin\\dot.exe", "-q", "-y", "-Kdot"} java.lang.Process process = Runtime.getRuntime().exec(args); Then we correspond with this process using its streams: BufferedOutputStream(process.getOutputStream()) graphvizStream = new GraphvizStream(process.getInputStream()); erg (administrator) 2015-01-19 16:19 Well, one thing I can say (assuming it isn't a typo), that pos value of "25.5,7000" for node1 is not good. cmot (reporter) 2015-01-21 11:04 Hi, I indeed think that 7000 might really be a typo'', because we tried to test if GraphViz can visualize a dot file that has coordinates already WITHOUT doing any re-layout... but we think GraphViz will always discard coordinate information and do a re-layout - right? We just played around with this because we wanted to have an easy way of reproducing the error. This is why we ended up in searching for a website that can render dot files. Interestingly we found that this website (s.a.) had the same issues with our example. To provide you with further information, I tweaked our tool to output the raw-dot-information it gets from GraphViz after each layout. I did some tests and collected a few good-examples and a few bad-examples (saved as dot-files). I attached them to this ticket: GraphVizBugRepotAdditionalInfo.zip Also you'll find a screenshot of our tool there that shows in the green debug view the raw coordinates it gets from GrapViz. In this screenshot you see the bad situation where an edge starts within a node. In 90% of the cases the edges start at the border of the node (good case). In the good case this is also reflected in the green debug view. I did not attach a good case screen shot. Does this information help you to nail down the problem?