octave-maintainers
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: uimenu implementation, 2nd version [octave_execution_exception]


From: Kai Habel
Subject: Re: uimenu implementation, 2nd version [octave_execution_exception]
Date: Fri, 29 Oct 2010 13:58:54 +0200
User-agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; de; rv:1.9.2.12) Gecko/20101027 Lightning/1.0b2 Thunderbird/3.1.6

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


Attachment: patch.crash
Description: Text document


reply via email to

[Prev in Thread] Current Thread [Next in Thread]