Thu 10 Mar 2016 07:41:54 PM UTC, comment #3:
The problem is in gl2ps_print.cc.
If the pipe is closed, because the command failed, then this code does not detect that condition nor raise an error. Instead, the call to gnulib::fwrite sends a signal SIGPIPE which is caught by Octave's signal handler over in sighandlers.cc.
Since the file being copied is quite large (potentially MB of eps data) the pipe_handler_error_count eventually exceeds 100 and Octave's interrupt state gets set. Thus, when the drawnow function call eventually returns the interpreter detects that and returns to the command line immediately bypassing the unwind_protect_cleanup blocks.
I tried this
and it seems to work. The possible changeset is attached to the report as SIGPIPE.cset, and needs review.
One thing I notice is that this sequence works.
But, it produces the extra message "warning: broken pipe". This comes from octave_signal_handler in sighandlers.cc. It is a minor quibble, but maybe it indicates that the patch should take a different direction. Instead of calling error when a bad pipe condition is detected it could call octave_signal_handler. That would reset the state of SIGPIPE, as well as print the warning message correctly attached to the command that caused it.
Or maybe we should be setting up Octave to ignore SIGPIPE signals when running this code. That sounds like more work, and I don't know exactly how to do it.
(file #36599)
|
Thu 10 Mar 2016 06:06:12 PM UTC, original submission:
The purpose of the unwind_protect/unwind_protect_cleanup construct is to be able to trap errors and recover if necessary. Unfortunately, I have discovered at least one exception to this when printing.
I've constructed a test script which tests a path of multiple unwind blocks.
When run without the call to print I see that each cleanup block is executed.
However, when I uncomment the line which calls print I get
The ordering of message in stdout is slightly messed up, but you can see that no cleanup blocks are ever executed.
This isn't about merely having C++ code. I used mkoctfile to build a DLDFCN which throws an error. Calling that function in place of print works correctly.
The first problem is why the Octave interpreter is not working correctly when print eventually invokes _osmesa_print_ at the bottom of _opengl_print_.m. The second question is whether there are other instances where this might happen such as GraphicsMagick or other DLDFCN libraries.
Incidentally, I tested with 'graphics_toolkit gnuplot' and then the script passes.
|