| CC: | <ron [...] savage.net.au> |
| Subject: | fdp.exe getting stuck on Windows under Apache |
| Date: | Fri, 26 Jul 2013 12:32:08 +0000 |
| To: | <bug-GraphViz2 [...] rt.cpan.org> |
| From: | <larry.knibb [...] nokia.com> |
Hi Ron,
I'm trying to get GraphViz2 (v2.14 with GraphViz 2.30) to work in a CGI script under Apache (mod_cgi) on Windows.
In a command line context it Just Works and I get the expected SVG output. In the CGI context it gets as far as the call to fdp.exe, which never returns. Apache eventually times-out and gives up trying to serve the page. The fdp.exe (sub)process
runs forever (until I kill it manually) with 0% CPU and ~3MB RAM.
I can simulate the issue by calling `fdp -T svg` with no input. That similarly waits forever for input.
So I suspect it's an issue with IPC::Run::run and mod_cgi but I can't find any comments on the web about IPC::Run::run not working under mod_cgi on Windows with regards to passing STDIN to subprocesses :|
Have you seen or heard of this issue before?
Maybe there's a tweak to the IPC::Run::run call (GraphViz2.pm:608) that can avoid the issue, or maybe the GraphViz2 library needs to support a two-stage invocation of GraphViz tools, e.g. 1. write DOT to file, 2. pass DOT as a file to <tool>.
I suppose I could create a dummy/noop driver and eval a call to that instead of fdp.exe, then grab the dot_input, write it to a temp DOT file and call fdp.exe myself with the DOT file... but that doesn't seem to be a nice solution.
Any ideas?
Cheers,
Larry