Graphviz Issue Tracker
Mantis Bug Tracker

View Issue Details Jump to Notes ] Issue History ] Print ]
IDProjectCategoryView StatusDate SubmittedLast Update
0002428graphvizDotpublic2014-03-03 13:402014-03-04 09:32
Assigned To 
PlatformWindowsOSWindows 7OS Version
Summary0002428: STDOUT doesn't get closed on large graphs?
DescriptionI'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!
TagsNo tags attached.
Attached Files

- Relationships

-  Notes
User avatar (0000699)
erg (administrator)
2014-03-03 22:18
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.

User avatar (0000700)
MindMusic (reporter)
2014-03-04 09:32

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. :)

- Issue History
Date Modified Username Field Change
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
Powered by Mantis Bugtracker