Re: segfault and onCleanup()

[John W. Eaton]

On  8-Dec-2011, Rik wrote:

| I'm now seeing the same segfault as Ben.  Using 'catch throw' and the
| following code which just starts and stops the interpreter I get a new
| backtrace.
| 
| sh> run-octave -g
| octave> exit
| 
| #0  0x00007ffff34acde0 in __cxa_throw () from /usr/lib/libstdc++.so.6
| #1  0x00007ffff595690c in octave_throw_interrupt_exception () at
| misc/quit.cc:57
| #2  0x00007ffff73bc5ab in Fquit (args=...) at toplev.cc:723
| #3  0x00007ffff741e673 in octave_builtin::do_multi_index_op (this=0x6d9d80,
| nargout=0, args=..., lvalue_list=0x0)
|     at ov-builtin.cc:131
| #4  0x00007ffff741e4db in octave_builtin::do_multi_index_op (this=0x6d9d80,
| nargout=0, args=...) at ov-builtin.cc:99
| #5  0x00007ffff74c49e0 in octave_value::do_multi_index_op
| (this=0x7fffffffcdd0, nargout=0, idx=...) at ov.cc:1268
| #6  0x00007ffff7554517 in tree_identifier::rvalue (this=0xc3abf0,
| nargout=0) at pt-id.cc:85
| #7  0x00007ffff755472e in tree_identifier::rvalue1 (this=0xc3abf0,
| nargout=0) at pt-id.cc:106
| #8  0x00007ffff7550bf7 in tree_evaluator::visit_statement
| (this=0x7ffff7ddbc98, stmt=...) at pt-eval.cc:739
| #9  0x00007ffff756f59a in tree_statement::accept (this=0xc6ff40, tw=...) at
| pt-stmt.cc:151
| #10 0x00007ffff7550de2 in tree_evaluator::visit_statement_list
| (this=0x7ffff7ddbc98, lst=...) at pt-eval.cc:775
| #11 0x00007ffff756f948 in tree_statement_list::accept (this=0xc79a60,
| tw=...) at pt-stmt.cc:215
| #12 0x00007ffff73bb5e6 in main_loop () at toplev.cc:595
| #13 0x00007ffff736e1dc in octave_main (argc=6, argv=0x7fffffffd2c8,
| embedded=0) at octave.cc:938
| #14 0x0000000000400769 in main (argc=6, argv=0x7fffffffd2c8) at main.c:35

Maybe I'm missing something, but that doesn't look like a segfault.
The quit function works by throwing an interrupt exception.  It is
supposed to be caught in main_loop in toplev.cc.  If that is not
happening, then you would see an abort on the uncaught exception.
Then the question is why isn't this exception being caught since
toplev.cc:595 is inside the try/catch block in main_loop.

If you do "catch catch" instead, is this exception caught?  If so,
does the segfault happen after this?  Is there a later exception that
is thrown and not caught?  If so, where is that one thrown?

jwe