[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: uimenu implementation, 2nd version [octave_execution_exception]
From: |
Ben Abbott |
Subject: |
Re: uimenu implementation, 2nd version [octave_execution_exception] |
Date: |
Sun, 31 Oct 2010 04:03:03 -0400 |
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
- Re: uimenu implementation, 2nd version [octave_execution_exception], (continued)
- Re: uimenu implementation, 2nd version [octave_execution_exception], Ben Abbott, 2010/10/27
- Re: uimenu implementation, 2nd version [octave_execution_exception], Kai Habel, 2010/10/27
- Re: uimenu implementation, 2nd version [octave_execution_exception], Kai Habel, 2010/10/29
- Re: uimenu implementation, 2nd version [octave_execution_exception], Ben Abbott, 2010/10/29
- Re: uimenu implementation, 2nd version [octave_execution_exception], Kai Habel, 2010/10/29
- Re: uimenu implementation, 2nd version [octave_execution_exception], Ben Abbott, 2010/10/29
- Re: uimenu implementation, 2nd version [octave_execution_exception], Kai Habel, 2010/10/29
- Re: uimenu implementation, 2nd version [octave_execution_exception], Ben Abbott, 2010/10/29
- Re: uimenu implementation, 2nd version [octave_execution_exception], Kai Habel, 2010/10/30
- Re: uimenu implementation, 2nd version [octave_execution_exception],
Ben Abbott <=
- Re: uimenu implementation, 2nd version [octave_execution_exception], Kai Habel, 2010/10/31
- Re: uimenu implementation, 2nd version [octave_execution_exception], Ben Abbott, 2010/10/31