|Anonymous | Login||2017-11-22 08:03 EST|
|Main | My View | View Issues | Change Log | Roadmap | My Account|
|View Issue Details|
|ID||Project||Category||View Status||Date Submitted||Last Update|
|0002428||graphviz||Dot||public||2014-03-03 13:40||2014-03-04 09:32|
|Platform||Windows||OS||Windows 7||OS Version|
|Summary||0002428: STDOUT doesn't get closed on large graphs?|
|Description||I'm generating a programmatically calling Dot from a .NET app. The app uses a very small third-party wrapper to generate a graph without explicitly opening a command shell, writing the resultant image files to disk, etc. ... I've also reported the error to the developers of the wrapper here...|
... but I don't think that they're the problem. The wrapper simply attaches two streams to StdIn and StdOut... sends the dot-formatting string to StdIn, then tries to copy the resultant PNG data back out of the StdOut. It does this copy with a simple C# call to the Stream.CopyTo(Stream) method. So far so good...
The problem only seems to occur when we pass in a larger digraph string (in my case, larger than a couple of dozen nodes?). The call to CopyTo seems to hang forever. According to MicroSoft, CopyTo will continue to attempt to copy until the stream is closed. I suspect that for larger graphs, Dot is not closing the stream after it renders the graph to StdOut under Windows.
I read a decade-old forum discussion...
... about this being intended functionality since Dot has the ability to render multiple graphs from one dot file, but it seemed to cause problems for the Windows guys at the time... I'm not sure that this is still the intended functionality. Also, I'm not sure why this would only be a problem with larger dot-formatting strings. Any ideas? Thanks in advance!
|Tags||No tags attached.|
edited on: 2014-03-03 22:34
I'm a bit confused. Isn't Stream.CopyTo() being used by GraphViz-C-Sharp-Wrapper to send the graph to Graphviz? In that case, Graphviz is reading from stdin, not stdout. And is your program hanging on writing or reading? Plus the original poster on the Github page talked about redirecting stderr and stdout.
In any case, without a small example .net program we can run to reproduce the problem, there is probably no way we can figure out what the problem might be.
As suggested by our earlier postings, synchronizing co-processes is difficult unless they are written to work together. If you are reading from a pipe, you should either parse the output, so you know when you are done, or terminate the co-process, e.g., by closing your stdout, which will cause the graphviz stdout to be closed, hence your stdin.
Thanks for your prompt reply... I apologize for the confusion. The code writes data to GraphViz's StdIn using WriteLine(dotFile)... it thereafter attempts to read the resultant PNG data out of GraphViz's StdOut using Stream.CopyTo() (and then hangs during this CopyTo()).
I'll see what I can do about making a small example program...
I do appreciate the difficulty of synchronizing co-processes. You are suggesting that I would have to parse the Png file's header so I know when Graphviz has sent me a complete PNG file, and then I'd know when to close the connection? So (to answer my original question) you're saying that GraphViz will NOT always close the StdOut pipe on it's own after it renders the dot file to a PNG? If you are counting on me to close the connection, and this is how GraphViz is designed to work, I just need to know that.
Thanks again for this fantastic project. :)
|2014-03-03 13:40||MindMusic||New Issue|
|2014-03-03 22:18||erg||Note Added: 0000699|
|2014-03-03 22:34||erg||Note Edited: 0000699||View Revisions|
|2014-03-04 09:32||MindMusic||Note Added: 0000700|
|MantisBT 1.2.5[^] Copyright © 2000 - 2011 MantisBT Group|