Wed 09 Nov 2011 09:51:47 AM UTC, comment #4:
Further findings:
I have built the entirety of octave-3.4.3 with -O0 and the hang still happens, however, I notice only the first plot hangs; you can hit ctrl+c and try again and it will work; as will subsequent plots.
I think we have a race condition on our hands and building with -O0 has changed the timings of things. After you have hit ctrl+c on the first plot, the only way to reproduce the plot hang is to reboot (weird, yes). This is why I think it is a race condition.
Further inspection with ktrace (like strace) shows differing behavior with regards to a fifo in /tmp.
A failing plot looks like this:
(The poll is the hang, notice the failed read() syscall).
Whereas the same area of execution on a working plot looks like:
(Notice that read DID NOT fail this time)
I suspscted the gnulib::mkfifo() at first, but if i remove the gnulib prefix, so as to use openbsd's implementation, the same happens.
Looks like a race condition to me (right?)
I am out of time for now, but my question now is, do we know where in the code this fifo is being made? Does gnuplot output to a pipe and octave picks it up? Is it the case that octave is reading from the pipe before gnuplot is done?
Comments and ideas welcome.
Cheers
|