Re: sigsev on exit with fltk backend

[Shai Ayal]

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?

It looks OK to me since the what the wait function does during the
timeout is wait for new events (it handles "old" events before the
timeout), so setting it to a short time shouldn't do any harm.

> 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).
>
OK

Shai