Re: uimenu implementation, 2nd version [octave_execution_exception]

[Ben Abbott]

On Oct 31, 2010, at 8:15 AM, Kai Habel wrote:

> On 31.10.2010 09:03, Ben Abbott wrote:
>> On Oct 30, 2010, at 12:55 PM, Kai Habel wrote:
>> 
>>> On 29.10.2010 15:32, Ben Abbott wrote:
>>>> On Oct 29, 2010, at 7:58 AM, Kai Habel wrote:
>>>> 
>>>>> Am 29.10.2010 11:29, schrieb Ben Abbott:
>>>>>> On Oct 29, 2010, at 4:31 PM, Kai Habel wrote:
>>>>>> 
>>>>>>> Am 29.10.2010 10:11, schrieb Ben Abbott:
>>>>>>>> On Oct 29, 2010, at 3:16 PM, Kai Habel wrote:
>>>>>>>> 
>>>>>>>>> Am 27.10.2010 09:56, schrieb Ben Abbott:
>>>>>>>>> 
>>>>>>>>> Ben,
>>>>>>>>> 
>>>>>>>>> I don't think the error is related to the call of error (msg). Can 
>>>>>>>>> you check this, by commenting out this line or placing an 
>>>>>>>>> input('press enter') before this line.
>>>>>>>> You are correct. When I comment out this line, the crash still occurs.
>>>>>>>> 
>>>>>>>>> I think the FLTK-GUI runs in "parallel" and is catching an mouse 
>>>>>>>>> event.
>>>>>>>>> 
>>>>>>>>> When looking at the backtrace, I see that  at #18 
>>>>>>>>> plot_window::handle() is called with event==1 (FL_PUSH?) and after 
>>>>>>>>> that plot_window::pixel2axes_or_ca (this=0x19123970, px=35,py=52). 
>>>>>>>>> This looks like valid pixel coordinates. Can you confirm that the 
>>>>>>>>> error happens during pixel2axes_or_ca. That should be possible with a 
>>>>>>>>> debugger, or you can place some debug statements in there e.g. 
>>>>>>>>> printf("before\n"); printf("after\n");
>>>>>>>>> 
>>>>>>>>> The crash seems to happen later in:
>>>>>>>>> #14 0x001ccadd in screen_size_pixels () at graphics.cc:541
>>>>>>>>> 
>>>>>>>>> where we have
>>>>>>>>> 
>>>>>>>>> #13 0x017b67ea in Matrix::extract_n (this=0xbfff85e8, r1=0, c1=2, 
>>>>>>>>> nr=1, nc=2)
>>>>>>>>> 
>>>>>>>>> ----------graphics.cc-----------
>>>>>>>>> // This function always returns the screensize in pixels
>>>>>>>>> 
>>>>>>>>> static Matrix
>>>>>>>>> screen_size_pixels (void)
>>>>>>>>> {
>>>>>>>>>   graphics_object obj = gh_manager::get_object (0);
>>>>>>>>>   Matrix sz = obj.get ("screensize").matrix_value ();
>>>>>>>>>   return convert_position (sz, obj.get ("units").string_value (), 
>>>>>>>>> "pixels", sz.extract_n (0, 2, 1, 2)).extract_n (0, 2, 1, 2);
>>>>>>>>> }
>>>>>>>>> -------------------------------------------------
>>>>>>>>> 
>>>>>>>>> It seems convert_position() is never called, because one of those 
>>>>>>>>> xxx.extract_n() calls fail.
>>>>>>>>> 
>>>>>>>>> Can you check there if all variables are ok there?
>>>>>>>>> 
>>>>>>>>> Kai
>>>>>>>> I'm a c++ flunky. It may be necessary for  you give me the commands I 
>>>>>>>> need to check the variables are ok.
>>>>>>>> 
>>>>>>>> I realize I should start with ...
>>>>>>>> 
>>>>>>>>        break graphics.cc:541
>>>>>>>> 
>>>>>>>> ... which stops at "return convert_position (...)"
>>>>>>>> 
>>>>>>>> Is it enough to then to ..
>>>>>>>> 
>>>>>>>>        print sz
>>>>>>>> 
>>>>>>>> Which gives ..
>>>>>>>> 
>>>>>>>> $1 = {
>>>>>>>>     <Array<double>>     = {
>>>>>>>>       rep = 0x2d6b7e0,
>>>>>>>>       dimensions = {
>>>>>>>>         rep = 0x2d7c6c8
>>>>>>>>       },
>>>>>>>>       slice_data = 0x4955440,
>>>>>>>>       slice_len = 4
>>>>>>>>     },<No data fields>},<No data fields>}
>>>>>>>> 
>>>>>>>> I can "continue" several times until the plot window appears with the 
>>>>>>>> uimenu, but then I'm unable to select the "clf" option since I have to 
>>>>>>>> go back to the command line and type "continue" again... hmm, I'm not 
>>>>>>>> being very clear. Hopefully you understand my problem with the 
>>>>>>>> debugger.
>>>>>>>> 
>>>>>>>> Is the a c++ command I can insert into the code to print the contents 
>>>>>>>> of "sz" to the command liine?
>>>>>>>> 
>>>>>>>> Ben
>>>>>>> I don't use gdb much, so I don't how to access sz from there. But if 
>>>>>>> you put in something like:
>>>>>>> 
>>>>>>> std::cout<<    "sz(0):"<<    sz(0)<<    ", sz(1):"<<    sz(1)<<    ", 
>>>>>>> sz(2):"<<    sz(2)<<    ", sz(3):"<<    sz(3)<<    std::endl;
>>>>>>> 
>>>>>>> that should give you the content of sz, with:
>>>>>>> sz(0) x0?
>>>>>>> sz(1) y0?
>>>>>>> sz(2) width
>>>>>>> sz(3) heigth
>>>>>>> 
>>>>>>> Kai
>>>>>> Ok. good call!
>>>>>> 
>>>>>> sz(0): 1, sz(1): 1, sz(2):1680, sz(3):1050
>>>>>> sz(0): 1, sz(1): 1, sz(2):1680, sz(3):1050
>>>>>> sz(0): 1, sz(1): 1, sz(2):1680, sz(3):1050
>>>>>> sz(0): 1, sz(1): 1, sz(2):1680, sz(3):1050
>>>>>> error: Invalid call to clf.  Correct usage is:
>>>>>> 
>>>>>>  -- Function File:  clf ()
>>>>>>  -- Function File:  clf ("reset")
>>>>>>  -- Function File:  clf (HFIG)
>>>>>>  -- Function File:  clf (HFIG, "reset")
>>>>>> 
>>>>>> 
>>>>>> Additional help for built-in functions and operators is
>>>>>> available in the on-line version of the manual.  Use the command
>>>>>> `doc<topic>' to search the manual index.
>>>>>> 
>>>>>> Help and information about Octave is also available on the WWW
>>>>>> at http://www.octave.org and via the address@hidden
>>>>>> mailing list.
>>>>>> sz(0): 1.93148e-288, sz(1): 2.122e-314, sz(2):0, sz(3):0
>>>>>> terminate called after throwing an instance of 
>>>>>> 'octave_execution_exception'
>>>>>> panic: Abort trap -- stopping myself...
>>>>>> attempting to save variables to `octave-core'...
>>>>>> save to `octave-core' complete
>>>>>> 
>>>>>> The last one is full of nonsense.
>>>>>> 
>>>>>> What next?
>>>>>> 
>>>>>> Ben
>>>>>> 
>>>>>> 
>>>>> Maybe it helps, if we check the validity of the root (?) object. Does the 
>>>>> attached patch help?
>>>>> 
>>>>> Kai
>>>>> <patch.crash>
>>>> I still get a crash. The backtrace is below.
>>>> 
>>>> terminate called after throwing an instance of 'octave_execution_exception'
>>>> 
>>>> Program received signal SIGABRT, Aborted.
>>>> 0x96a42ef6 in __kill ()
>>>> (gdb) bt
>>>> #0  0x96a42ef6 in __kill ()
>>>> #1  0x96a42ee8 in kill$UNIX2003 ()
>>>> #2  0x96ad562d in raise ()
>>>> #3  0x96aeb6e4 in abort ()
>>>> #4  0x903bffda in __gnu_cxx::__verbose_terminate_handler ()
>>>> #5  0x903be17a in __cxxabiv1::__terminate ()
>>>> #6  0x903be1ba in std::terminate ()
>>>> #7  0x903be2b8 in __cxa_throw ()
>>>> #8  0x02531e2f in octave_throw_execution_exception () at misc/quit.cc:67
>>>> #9  0x003b73f4 in lo_error_with_id_handler (id=Could not find the frame 
>>>> base for "lo_error_with_id_handler(char const*, char const*, ...)".
>>>> ) at octave.cc:546
>>>> #10 0x01345046 in gripe_index_out_of_range (nd=2, dim=1, idx=1, ext=0) at 
>>>> lo-array-gripes.cc:105
>>>> #11 0x01402a23 in idx_vector::extent () at 
>>>> /Users/bpabbott/Development/mercurial/local_clone/liboctave/idx-vector.h:779
>>>> #12 0x01402a23 in Array<double>::index (this=0xbfff8638, address@hidden, 
>>>> address@hidden) at Array.cc:780
>>>> #13 0x017b57ea in Matrix::extract_n (this=0xbfff8638, r1=0, c1=2, nr=1, 
>>>> nc=2) at dMatrix.cc:589
>>>> #14 0x001b59ab in screen_size_pixels () at graphics.cc:545
>>>> #15 0x001fe7df in figure::properties::get_boundingbox (this=0x324bc08) at 
>>>> graphics.cc:2771
>>>> #16 0x0020c520 in axes::properties::get_boundingbox (this=0x326a008, 
>>>> internal=true) at graphics.cc:3968
>>>> #17 0x047142e3 in plot_window::pixel2axes_or_ca (this=0x42add20, px=54, 
>>>> py=57) at DLD-FUNCTIONS/fltk_backend.cc:988
>>>> #18 0x0471a606 in plot_window::handle (this=0x42add20, event=1) at 
>>>> DLD-FUNCTIONS/fltk_backend.cc:1223
>>>> #19 0x027ea702 in send ()
>>>> #20 0x027edece in Fl::handle ()
>>>> #21 0x027f023f in carbonMouseHandler ()
>>>> #22 0x9613ff2f in DispatchEventToHandlers ()
>>>> #23 0x9613f1f6 in SendEventToEventTargetInternal ()
>>>> #24 0x961619bb in SendEventToEventTarget ()
>>>> #25 0x961734db in ToolboxEventDispatcherHandler ()
>>>> #26 0x96140380 in DispatchEventToHandlers ()
>>>> #27 0x9613f1f6 in SendEventToEventTargetInternal ()
>>>> #28 0x961ac441 in CallNextEventHandler ()
>>>> #29 0x027ed022 in carbonDispatchHandler ()
>>>> #30 0x9613ff2f in DispatchEventToHandlers ()
>>>> #31 0x9613f1f6 in SendEventToEventTargetInternal ()
>>>> #32 0x961619bb in SendEventToEventTarget ()
>>>> #33 0x027ecb22 in do_queued_events ()
>>>> #34 0x027ecccd in Fl::wait ()
>>>> #35 0x027ecd07 in Fl::check ()
>>>> #36 0x04702bc4 in __fltk_redraw__ () at DLD-FUNCTIONS/fltk_backend.cc:1744
>>>> #37 0x04702c25 in F__fltk_redraw__ () at DLD-FUNCTIONS/fltk_backend.cc:1876
>>>> #38 0x004a2d26 in octave_builtin::do_multi_index_op (this=0x30747e0, 
>>>> nargout=0, address@hidden, lvalue_list=0x0) at ov-builtin.cc:129
>>>> #39 0x004a30ff in octave_builtin::do_multi_index_op (this=0x30747e0, 
>>>> nargout=0, address@hidden) at ov-builtin.cc:99
>>>> #40 0x0008049a in octave_value::do_multi_index_op (this=0xbfff9ec8, 
>>>> nargout=0, address@hidden) at ov.cc:1267
>>>> #41 0x00060e95 in feval (address@hidden, address@hidden, nargout=0) at 
>>>> oct-parse.yy:4130
>>>> #42 0x002aa4a4 in input_event_hook () at input.cc:1262
>>>> #43 0x01ca1633 in command_editor::event_handler () at cmd-edit.cc:889
>>>> #44 0x02bb75ec in rl_read_key ()
>>>> #45 0x02b9f9f8 in readline_internal_char ()
>>>> #46 0x02b9fbc4 in readline_internal_charloop ()
>>>> #47 0x02b9fbec in readline_internal ()
>>>> #48 0x02b9f6ac in readline ()
>>>> #49 0x01ca276e in gnu_readline::do_readline (this=0x2d546f0, 
>>>> address@hidden, address@hidden) at cmd-edit.cc:253
>>>> #50 0x01ca2669 in command_editor::readline (address@hidden, 
>>>> address@hidden) at cmd-edit.cc:914
>>>> #51 0x0003bdf5 in gnu_readline (address@hidden, force_readline=false) at 
>>>> input.cc:205
>>>> #52 0x0003dc7f in interactive_input (address@hidden, force_readline=<value 
>>>> temporarily unavailable, due to optimizations>) at input.cc:251
>>>> #53 0x0003dea4 in std::string::operator= () at 
>>>> /usr/include/c++/4.2.1/bits/basic_string.h:281
>>>> #54 0x0003dea4 in octave_gets [inlined] () at 
>>>> /Users/bpabbott/Development/mercurial/local_clone/src/input.cc:281
>>>> #55 get_user_input [inlined] () at 
>>>> /Users/bpabbott/Development/mercurial/local_clone/src/input.cc:352
>>>> #56 0x0003dea4 in octave_read (buf=0x382cc00 "", max_size=8192) at 
>>>> input.cc:374
>>>> #57 0x0003f153 in yy_get_next_buffer () at lex.cc:3098
>>>> #58 0x0005015d in octave_lex () at lex.cc:2940
>>>> #59 0x00066bd4 in octave_parse () at oct-parse.cc:2409
>>>> #60 0x00423194 in main_loop () at toplev.cc:564
>>>> #61 0x003bec32 in octave_main (argc=6, argv=0xbfffb040, embedded=0) at 
>>>> octave.cc:894
>>>> #62 0x00001f80 in main (argc=6, argv=0xbfffb040) at main.c:35
>>>> (gdb)
>>>> 
>>>> Ben
>>>> 
>>> Ben,
>>> 
>>> I have no further ideas what to look at. So, the failing object claims to 
>>> be valid but has invalid properties. Hmm, I do not know how this can 
>>> happen. Maybe John has an idea?
>>> 
>>> Or, maybe it is an compiler bug - in that case it could help to compile 
>>> without optimisation. If we don't find a solution now, please make an entry 
>>> in the bug tracker in a few days.
>>> 
>>> Kai
>> I tried compiling with "-O0", but the crash still occurs.
>> 
>> I'll try to simplify the conditions needed to create the crash.
>> 
>> Ben
>> 
> Do you also get the crash when you use another callback e.g.
> 
> set(gcf,'windowbuttondownfcn',@clf)
> 
> and you click on the current figure?
> 
> Kai

I get the error, "error: Invalid call to clf.  Correct usage is:", but Octave 
does not crash.

Ben