Re: EXC_BAD_ACCESS [was: persistent listeners]

[Søren Hauberg]

lør, 12 03 2011 kl. 23:06 +0100, skrev logari81:
> On Sat, 2011-03-12 at 16:42 -0500, Ben Abbott wrote:
> > On Mar 12, 2011, at 4:26 PM, logari81 wrote:
> > 
> > > On Sat, 2011-03-12 at 16:14 -0500, Ben Abbott wrote:
> > >> On Mar 12, 2011, at 12:55 PM, Ben Abbott wrote:
> > >> 
> > >>> On Mar 12, 2011, at 11:59 AM, Ben Abbott wrote:
> > >>> 
> > >>>> On Mar 12, 2011, at 3:10 AM, logari81 wrote:
> > >>>> 
> > >>>>> On Thu, 2011-03-10 at 21:20 +0000, bpabbott wrote:
> > >>>>>> On Mar 10, 2011, at 02:34 PM, Konstantinos Poulios
> > >>>>>> <address@hidden> wrote:
> > >>>>>> 
> > >>>>>>> On Wed, Mar 9, 2011 at 12:16 PM, Konstantinos Poulios
> > >>>>>>> <address@hidden> wrote:
> > >>>>>>>> In the new implementation of subplot we have the problem that the
> > >>>>>>>> listeners that we use for the synchronization of subplots are
> > >>>>>>> deleted
> > >>>>>>>> once something is plotted on a subplot.
> > >>>>>>>> 
> > >>>>>>>> The attached patches implement persistent listeners, i.e.:
> > >>>>>>>> 
> > >>>>>>>> 1. listeners added with:
> > >>>>>>>> addlistener (handle, propertyname, cbfunction, "persistent")
> > >>>>>>>> will not be removed by the c++ method "remove_all_listeners", nor
> > >>>>>>> by a
> > >>>>>>>> call to delete_listener() with empty arguments list.
> > >>>>>>>> 
> > >>>>>>>> 2. however, explicitly removing a persistent listener from the
> > >>>>>>> frontend with:
> > >>>>>>>> dellistener (handle, propertyname, cbfunction)
> > >>>>>>>> should still work.
> > >>>>>>>> 
> > >>>>>>>> Please take a look at the patches so that I can push them if it is
> > >>>>>>> ok,
> > >>>>>>>> so that we can make some progress with the subplot fixes.
> > >>>>>>>> 
> > >>>>>>>> Kostas
> > >>>>>>> 
> > >>>>>>> I have just pushed a modified/fixed version of these patches.
> > >>>>>>> Actually
> > >>>>>>> with a bit modified policy than the one described in my previous
> > >>>>>>> mail:
> > >>>>>>> 
> > >>>>>>> 1. One can add a persistent listener with
> > >>>>>>> addlistener (handle, propertyname, cbfunction, "persistent")
> > >>>>>>> 
> > >>>>>>> 2 One can delete all persistent listeners on a property with
> > >>>>>>> dellistener (handle, propertyname, "persistent")
> > >>>>>>> 
> > >>>>>>> This change will allow us to fix the known issues with subplot.
> > >>>>>>> 
> > >>>>>>> Regards
> > >>>>>>> 
> > >>>>>>> Kostas
> > >>>>>> 
> > >>>>>> With this in place, Octave crashes for me when I try to create a plot
> > >>>>>> with fltk active.
> > >>>>>> 
> > >>>>>> 
> > >>>>>> octave:1> graphics_toolkit fltk
> > >>>>>> 
> > >>>>>> Reading symbols for shared libraries . done
> > >>>>>> 
> > >>>>>> Reading symbols for shared libraries . done
> > >>>>>> 
> > >>>>>> octave:2> plot (1:10)
> > >>>>>> 
> > >>>>>> Reading symbols for shared libraries . done
> > >>>>>> 
> > >>>>>> 
> > >>>>>> Program received signal EXC_BAD_ACCESS, Could not access memory.
> > >>>>>> 
> > >>>>>> Reason: KERN_PROTECTION_FAILURE at address: 0x00000000
> > >>>>>> 
> > >>>>>> 0x927d725e in glMatrixMode ()
> > >>>>>> 
> > >>>>>> (gdb) bt
> > >>>>>> 
> > >>>>>> #0  0x927d725e in glMatrixMode ()
> > >>>>>> 
> > >>>>>> #1  0x03705dbe in OpenGL_fltk::setup_viewport ()
> > >>>>>> at 
> > >>>>>> /Users/bpabbott/Development/mercurial/octave/src/DLD-FUNCTIONS/__init_fltk__.cc:146
> > >>>>>> 
> > >>>>>> #2  0x03705dbe in OpenGL_fltk::resize (this=0x3609a50, xx=0, yy=20,
> > >>>>>> ww=640, hh=440) at DLD-FUNCTIONS/__init_fltk__.cc:129
> > >>>>>> 
> > >>>>>> #3  0x037155d6 in fltk_uimenu::show ()
> > >>>>>> at 
> > >>>>>> /Users/bpabbott/Development/mercurial/octave/src/DLD-FUNCTIONS/__init_fltk__.cc:788
> > >>>>>> 
> > >>>>>> #4  0x037155d6 in plot_window::show_menubar ()
> > >>>>>> at 
> > >>>>>> /Users/bpabbott/Development/mercurial/octave/src/DLD-FUNCTIONS/__init_fltk__.cc:789
> > >>>>>> 
> > >>>>>> #5  0x037155d6 in plot_window::plot_window (this=0x36094d0, xx=0,
> > >>>>>> yy=0, ww=640, hh=480, address@hidden) at
> > >>>>>> DLD-FUNCTIONS/__init_fltk__.cc:737
> > >>>>>> 
> > >>>>>> #6  0x03715caa in plot_window [inlined] ()
> > >>>>>> at 
> > >>>>>> /Users/bpabbott/Development/mercurial/octave/src/DLD-FUNCTIONS/__init_fltk__.cc:755
> > >>>>>> 
> > >>>>>> #7  0x03715caa in figure_manager::do_new_window (this=0x33b8870,
> > >>>>>> address@hidden) at DLD-FUNCTIONS/__init_fltk__.cc:1572
> > >>>>>> 
> > >>>>>> #8  0x037042bb in figure_manager::new_window ()
> > >>>>>> at 
> > >>>>>> /Users/bpabbott/Development/mercurial/octave/src/DLD-FUNCTIONS/__init_fltk__.cc:1450
> > >>>>>> 
> > >>>>>> #9  0x037042bb in __fltk_redraw__ () at
> > >>>>>> DLD-FUNCTIONS/__init_fltk__.cc:1767
> > >>>>>> 
> > >>>>>> #10 0x03715f77 in fltk_graphics_toolkit::redraw_figure
> > >>>>>> (this=0x3606c40, address@hidden) at
> > >>>>>> DLD-FUNCTIONS/__init_fltk__.cc:1865
> > >>>>>> 
> > >>>>>> #11 0x001fdef4 in graphics_toolkit::redraw_figure ()
> > >>>>>> at /Users/bpabbott/Development/mercurial/octave/src/graphics.h:7618
> > >>>>>> 
> > >>>>>> #12 0x001fdef4 in Fdrawnow (address@hidden) at graphics.cc:7618
> > >>>>>> 
> > >>>>>> #13 0x00498fad in octave_builtin::do_multi_index_op (this=0x3864140,
> > >>>>>> nargout=0, address@hidden, lvalue_list=0x0) at ov-builtin.cc:128
> > >>>>>> 
> > >>>>>> #14 0x00499377 in octave_builtin::do_multi_index_op (this=0x3864140,
> > >>>>>> nargout=0, address@hidden) at ov-builtin.cc:98
> > >>>>>> 
> > >>>>>> #15 0x0007e578 in octave_value::do_multi_index_op (this=0xbfffb518,
> > >>>>>> nargout=0, address@hidden) at ov.cc:1266
> > >>>>>> 
> > >>>>>> #16 0x0005d5f1 in feval (address@hidden, address@hidden,
> > >>>>>> nargout=0) at oct-parse.yy:4140
> > >>>>>> 
> > >>>>>> #17 0x0003af99 in interactive_input (address@hidden,
> > >>>>>> force_readline=false) at input.cc:237
> > >>>>>> 
> > >>>>>> #18 0x0003ba25 in std::string::operator= () at /usr/include/c
> > >>>>>> ++/4.2.1/bits/basic_string.h:280
> > >>>>>> 
> > >>>>>> #19 0x0003ba25 in octave_gets [inlined] ()
> > >>>>>> at /Users/bpabbott/Development/mercurial/octave/src/input.cc:280
> > >>>>>> 
> > >>>>>> #20 get_user_input [inlined] ()
> > >>>>>> at /Users/bpabbott/Development/mercurial/octave/src/input.cc:351
> > >>>>>> 
> > >>>>>> #21 0x0003ba25 in octave_read (buf=0x3a50600 "", max_size=8192) at
> > >>>>>> input.cc:373
> > >>>>>> 
> > >>>>>> #22 0x0003ccd3 in yy_get_next_buffer () at lex.cc:3097
> > >>>>>> 
> > >>>>>> #23 0x0004df11 in octave_lex () at lex.cc:2939
> > >>>>>> 
> > >>>>>> #24 0x00063a9d in octave_parse () at oct-parse.cc:2395
> > >>>>>> 
> > >>>>>> #25 0x0041a5c9 in main_loop () at toplev.cc:567
> > >>>>>> 
> > >>>>>> #26 0x003b591d in octave_main (argc=6, argv=0xbfffc354, embedded=0) 
> > >>>>>> at
> > >>>>>> octave.cc:935
> > >>>>>> 
> > >>>>>> #27 0x00001f80 in main (argc=6, argv=0xbfffc354) at main.c:35
> > >>>>>> 
> > >>>>>> 
> > >>>>>> Occasionally, I see some strange results on MacOS. Can someone else
> > >>>>>> confirm this behavior?
> > >>>>>> 
> > >>>>>> Ben
> > >>>>> 
> > >>>>> Hmm, this is very strange because normal plotting shouldn't involve 
> > >>>>> any
> > >>>>> listeners at all, should it? I couldn't reproduce this issue on two
> > >>>>> different computers but I cannot try it on a Mac.
> > >>>>> 
> > >>>>> Have you tried rebuilding everything from scratch?
> > >>>>> 
> > >>>>> Kostas
> > >>>> 
> > >>>> I don't see this on Ubuntu, but am able to reproduce in on two Macs. 
> > >>>> The root of the problem may be due to fltk-aqua-1.1.10 , the older gcc 
> > >>>> 4.2.1 I'm using, or Apple's patches to gcc. 
> > >>>> 
> > >>>> Ben
> > >>> 
> > >>> Kostas,
> > >>> 
> > >>> I just confirmed your changeset (12505) is not the cause of the 
> > >>> problem. After reverting it, I still get a core-dump.
> > >>> 
> > >>> I'll try to isolate the problem.
> > >>> 
> > >>> Ben
> > >> 
> > >> I've isolated the problem to the change below.
> > >> 
> > >> http://hg.savannah.gnu.org/hgweb/octave/diff/9c831d357e6f/src/DLD-FUNCTIONS/__init_fltk__.cc
> > >> 
> > >> Without this change, I don't get the crash.
> > >> 
> > >> Ben
> > > 
> > > aha, this patch consists of two parts. Could you first apply only the
> > > changes below: @@ -776,28 +780,28 @@
> > > and see if this triggers the issue. If not, then we will have isolated
> > > the problem in the first part.
> > > 
> > > I have also cc'd the original author of __init_fltk__.cc, so that he
> > > maybe can review my patch.
> > > 
> > > Kostas
> > 
> > I had the same thought. After a few experiments, I've isolated the problem. 
> > Does this change interfere with the intent of your changeset?
> > 
> > Ben
> > 
> > 
> > 
> 
> Yes your last change would cancel my intention in my previous change.
> The idea is that the lines:
> 
> ||    if (uimenu->items_to_show ())
> ||      show_menubar ();
> ||    else
> ||      hide_menubar ();
> 
> should be before the first allocation of the canvas:
> 
> ||      // This allows us to have a valid OpenGL context right away.
> ||      canvas->mode (FL_DEPTH | FL_DOUBLE );
> ||      if (fp.is_visible ())
> ||        {
> ||          show ();
> ||          if (fp.get_currentaxes ().ok())
> ||            show_canvas ();
> ||          else
> ||            hide_canvas ();
> ||        }
> 
> otherwise, at least with my fltk version, the first time anything is
> plotted is vertically shifted by the menu bar height which was very
> annoying.
> 
> So we have to find some other solution. Maybe Shai could give us a hint.

I haven't really been following this thread, so I might be way of
here... but it sounds like you're re-introducing this bug:

https://savannah.gnu.org/bugs/?31931


Maybe you should look at how this was fixed?

Søren