Re: uimenu implementation, 2nd version [octave_execution_exception]

[Ben Abbott]

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