Re: EXC_BAD_ACCESS [was: persistent listeners]

[Ben Abbott]

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