Re: how to localise a problem?

[McA]

in reply to how to localise a problem?

Hi,

that looks like something is accumulating over time. So I would look at objects, variables which are probably used more then once over the time. Probably they are not initialized properly on every run. Another guess is that you expect that a object is shutdown correctly while going out of scope but it doesn't. Check the manual of the "bigger" objects you use.

UPDATE: I just looked at the GraphViz2 (2.06) package. It seems that there is exactly one line where IPC::Run is used:

$self -> dot_input(join('', @{$self -> command -> print} ) . "}\n");
$self -> log(debug => $self -> dot_input);

my($stdout, $stderr);

IPC::Run::run([$driver, "-T$format"], \$self -> dot_input, \$stdout, \
+$stderr);

So, the dot_input is logged if logging is enabled. Probably the right point to catch the culprit.

Best regards
McA

[Dave Howorth]

Hi McA, thanks for your input. You were quite right about hacking Graphviz vs IPC::Run. I made a change almost identical to what you suggested. Now I'm just waiting for another crash.

Uninitialised or left-over objects is usually my first thought with this kind of problem (don't ask me how I know!) but I'm not seeing any signs of steady process growth. It's also a rather odd method of crashing for an OOM fault, although it is still a possibility.

So I'll see what the next lot of diagnostics shows me. Hopefully I won't have to iterate too many times until I find the root cause.

[McA]

Have you found the bug. I'm really curious.

Best regards
McA