Re: sigsev on exit with fltk backend

[Jaroslav Hajek]

2009/12/16 John W. Eaton <address@hidden>:
> On 16-Dec-2009, Shai Ayal wrote:
>
> | On Wed, Dec 16, 2009 at 6:16 AM, Shai Ayal <address@hidden> wrote:
> | > Hi
> | >
> | > Can anyone help with the following problem (current tip):
> | >
> | > lt-octave:1> backend ("fltk");
> | > lt-octave:2> quit
> | >
> | >
> | > Program received signal SIGSEGV, Segmentation fault.
> | > 0xb76203be in std::_Rb_tree<std::string, std::pair<std::string const,
> | > graphics_backend>, std::_Select1st<std::pair<std::string const,
> | > graphics_backend> >, std::less<std::string>,
> | > std::allocator<std::pair<std::string const, graphics_backend> >
> | >>::_M_erase(std::_Rb_tree_node<std::pair<std::string const,
> | > graphics_backend> >*) ()
> | >   from /home/shaia/hack/octave-working/src/.libs/liboctinterp-3.3.50+.so
> | > (gdb) bt
> | > #0  0xb76203be in std::_Rb_tree<std::string, std::pair<std::string
> | > const, graphics_backend>, std::_Select1st<std::pair<std::string const,
> | > graphics_backend> >, std::less<std::string>,
> | > std::allocator<std::pair<std::string const, graphics_backend> >
> | >>::_M_erase(std::_Rb_tree_node<std::pair<std::string const,
> | > graphics_backend> >*) ()
> | >   from /home/shaia/hack/octave-working/src/.libs/liboctinterp-3.3.50+.so
> | > #1  0xb7620424 in std::map<std::string, graphics_backend,
> | > std::less<std::string>, std::allocator<std::pair<std::string const,
> | > graphics_backend> > >::~map() ()
> | >   from /home/shaia/hack/octave-working/src/.libs/liboctinterp-3.3.50+.so
> | > #2  0xb4d09828 in __cxa_finalize () from /lib/i686/cmov/libc.so.6
> | > #3  0xb7487604 in __do_global_dtors_aux ()
> | >   from /home/shaia/hack/octave-working/src/.libs/liboctinterp-3.3.50+.so
> | > #4  0xb7dcadb0 in _fini () from
> | > /home/shaia/hack/octave-working/src/.libs/liboctinterp-3.3.50+.so
> | > #5  0xb7ff0b7b in ?? () from /lib/ld-linux.so.2
> | > #6  0xb4d09481 in ?? () from /lib/i686/cmov/libc.so.6
> | > #7  0xb4d094df in exit () from /lib/i686/cmov/libc.so.6
> | > #8  0xb77a64fa in clean_up_and_exit (retval=0) at toplev.cc:684
> | > #9  0xb77a6c0f in main_loop () at toplev.cc:628
> | > #10 0xb774ef36 in octave_main (argc=6, argv=0xbfffe6c4, embedded=0) at
> | > octave.cc:887
> | > #11 0x08048783 in main (argc=6, argv=0xbfffe6c4) at main.c:35
> | >
> |
> | Reverting to rev 9794 of toplev.cc solves this problem
>
> I checked in the following change that also avoids the problem while
> still allowing the symbol table to be cleared.
>
>    http://hg.savannah.gnu.org/hgweb/octave/rev/1300d9ced492
>
> Note that I reduced the wait time from 10 seconds to fltk_maxtime.
> I'm not sure that's the right thing to do, but it seems unreasonable
> to me to have to unconditionally wait 10 seconds for the graphics
> system to shut down.  What is the harm in not waiting for events when
> removing the fltk backend?  How can you know that all events have
> arrived within any given period of time?
>
> Also, it should be safe to leave the __remove_fltk__ function on the
> list of atexit functions since it is safe to call __remove_fltk__ when
> the fltk backend is not registered.  That seemed simpler to do than
> trying to decide when it is safe to remove the function from the list
> (i.e., I don't think it is safe to do so when the list of functions is
> being executed from do_octave_atexit).
>
> Does this look OK to you?
>
> jwe
>

Thanks. I checked in a minor change to symbol_table::cleanup
(substituted clear_all by clear_variables, because functions are
cleared anyway). So the cleanup sequence is now:

1. clear variables from top level scope (command-line workspace)
2. clear unconditionally all functions
3. clear global variables
4. clear all remaining scopes and remove them from the table

in theory, functions remove their scopes when cleared, so 4. should
essentially only remove the top and global scope (already empty). I'm
not sure about the order of 2 and 3. Maybe it should be the other way
around?

regards

-- 
RNDr. Jaroslav Hajek
computing expert & GNU Octave developer
Aeronautical Research and Test Institute (VZLU)
Prague, Czech Republic
url: www.highegg.matfyz.cz