Re: segfault and onCleanup()

[Rik]

On 12/08/2011 11:26 AM, John W. Eaton wrote:
> ks 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"

Running the following code:
sh> run-octave -g
gdb> catch catch
gdb> run
octave> exit
 
I get

Catchpoint 1 (exception caught), 0x00007ffff34abcd0 in __cxa_begin_catch () from /usr/lib/libstdc++.so.6
(gdb) bt
#0  0x00007ffff34abcd0 in __cxa_begin_catch () from /usr/lib/libstdc++.so.6
#1  0x00007ffff73bb967 in main_loop () at toplev.cc:635                                                                         
#2  0x00007ffff736e3dc in octave_main (argc=6, argv=0x7fffffffd2c8, embedded=0) at octave.cc:938                                
#3  0x0000000000400769 in main (argc=6, argv=0x7fffffffd2c8) at main.c:35

From there I can single step through the code.  The relevant lines from toplev.cc are

637               recover_from_exception ();
638               octave_stdout << "\n";
639               if (quitting_gracefully)
640                 {
641                   clean_up_and_exit (exit_status);

I single step to the function call clean_up_and_exit which then generates a segfault.  The backtrace is

#0  0x00007ffff70be340 in ~graphics_toolkit (this=0xc73c88, __in_chrg=<value optimized out>) at graphics.h:2177
#1  0x00007ffff7244a7f in ~pair (this=0xc73c80, __in_chrg=<value optimized out>) at /usr/include/c++/4.4/bits/stl_pair.h:68
#2  0x00007ffff72544f4 in __gnu_cxx::new_allocator<std::pair<std::string const, graphics_toolkit> >::destroy(std::pair<std::string const, graphics_toolkit>*) () from /home/rik/wip/Projects_Mine/octave-dbg/src/.libs/liboctinterp.so.0
#3  0x00007ffff724ff53 in std::_Rb_tree<std::string, std::pair<std::string const, graphics_toolkit>, std::_Select1st<std::pair<std::string const, graphics_toolkit> >, std::less<std::string>, std::allocator<std::pair<std::string const, graphics_toolkit> > >::_M_destroy_node(std::_Rb_tree_node<std::pair<std::string const, graphics_toolkit> >*) ()
   from /home/rik/wip/Projects_Mine/octave-dbg/src/.libs/liboctinterp.so.0
#4  0x00007ffff7250093 in std::_Rb_tree<std::string, std::pair<std::string const, graphics_toolkit>, std::_Select1st<std::pair<std::string const, graphics_toolkit> >, std::less<std::string>, std::allocator<std::pair<std::string const, graphics_toolkit> > >::_M_erase(std::_Rb_tree_node<std::pair<std::string const, graphics_toolkit> >*) ()
   from /home/rik/wip/Projects_Mine/octave-dbg/src/.libs/liboctinterp.so.0
#5  0x00007ffff724a5a5 in ~_Rb_tree (this=0x7ffff7dd5860, __in_chrg=<value optimized out>)
    at /usr/include/c++/4.4/bits/stl_tree.h:614
#6  0x00007ffff7257c80 in std::map<std::string, graphics_toolkit, std::less<std::string>, std::allocator<std::pair<std::string const, graphics_toolkit> > >::~map() () from /home/rik/wip/Projects_Mine/octave-dbg/src/.libs/liboctinterp.so.0
#7  0x00007ffff50a8630 in __cxa_finalize (d=0x7ffff7da3fe0) at cxa_finalize.c:56
#8  0x00007ffff7001756 in __do_global_dtors_aux () from /home/rik/wip/Projects_Mine/octave-dbg/src/.libs/liboctinterp.so.0
#9  0x0000000000000000 in ?? ()

Further single-stepping shows that it is this call in toplev.cc at line 685 that causes the problem.

    (*octave_exit) (retval == EOF ? 0 : retval);

--Rik