base_graphics_backend

classic Classic list List threaded Threaded
17 messages Options
Reply | Threaded
Open this post in threaded view
|

base_graphics_backend

Ryan Rusaw
Michael,

I've implemented a implement a subclass of base_graphics_backend that
implements a simple wire protocol with JSON-based data serialization.
I've just encountered a few issues

1. A property_changed event is never fired for
base_properties::children. Is this the expected behavior? I've
resorted to keeping track of children
myself on the plotting end of the ipc socket, as I never know when the
children have been updated.

2. I seem to get spurious object deletions and incomplete handle reassignments.

octave:1> autoload("__init_octave_eclipse__",
file_in_loadpath("octave_eclipse_backend.oct"))
octave:2> backend ("octave_eclipse")
octave:3> figure
octave:4> plot(0:.1:10,cos(0:.1:10))
octave:5> exit
error: graphics_handle::free: invalid object -6.19755
error: graphics_handle::free: invalid object -7.33522
error: graphics_handle::free: invalid object -8.76823
error: graphics_handle::free: invalid object -9.27777

Printing out the serialized objects I get the following:

{"payload":{"objectCreated":{"object":{"properties":[{"key":"__myhandle__","value":{"double_value":1}},{"key":"type","value":{"string_value":"figure"}}]}}}}
{"payload":{"objectCreated":{"object":{"properties":[{"key":"__myhandle__","value":{"double_value":-1.840187716837885}},{"key":"type","value":{"string_value":"axes"}}]}}}}
{"payload":{"objectCreated":{"object":{"properties":[{"key":"__myhandle__","value":{"double_value":-2.394382926917457}},{"key":"type","value":{"string_value":"text"}}]}}}}
{"payload":{"objectCreated":{"object":{"properties":[{"key":"__myhandle__","value":{"double_value":-3.783099223494949}},{"key":"type","value":{"string_value":"text"}}]}}}}
{"payload":{"objectCreated":{"object":{"properties":[{"key":"__myhandle__","value":{"double_value":-4.798440033198129}},{"key":"type","value":{"string_value":"text"}}]}}}}
{"payload":{"objectCreated":{"object":{"properties":[{"key":"__myhandle__","value":{"double_value":-5.911647357553408}},{"key":"type","value":{"string_value":"text"}}]}}}}
{"payload":{"objectCreated":{"object":{"properties":[{"key":"__myhandle__","value":{"double_value":-6.197551369575061}},{"key":"type","value":{"string_value":"text"}}]}}}}
{"payload":{"objectCreated":{"object":{"properties":[{"key":"__myhandle__","value":{"double_value":-7.33522275586835}},{"key":"type","value":{"string_value":"text"}}]}}}}
{"payload":{"objectCreated":{"object":{"properties":[{"key":"__myhandle__","value":{"double_value":-8.768229594562095}},{"key":"type","value":{"string_value":"text"}}]}}}}
{"payload":{"objectCreated":{"object":{"properties":[{"key":"__myhandle__","value":{"double_value":-9.277774711010151}},{"key":"type","value":{"string_value":"text"}}]}}}}
{"payload":{"objectDeleted":{"object_id":-6.197551369575061}}}
{"payload":{"objectDeleted":{"object_id":-7.33522275586835}}}
{"payload":{"objectDeleted":{"object_id":-8.768229594562095}}}
{"payload":{"objectDeleted":{"object_id":-9.277774711010151}}}
{"payload":{"objectCreated":{"object":{"properties":[{"key":"__myhandle__","value":{"double_value":-9.277774711010151}},{"key":"type","value":{"string_value":"hggroup"}}]}}}}
{"payload":{"objectCreated":{"object":{"properties":[{"key":"__myhandle__","value":{"double_value":-8.768229594562095}},{"key":"type","value":{"string_value":"line"}}]}}}}

It seems to create the figure and axes correctly, but then creates
extra text objects ([xyz]label + title) just to delete them again.
Could this be a byproduct of iterating through all the properties of
an object during the object_created function call?

void octave_eclipse_backend::object_created(const graphics_object& go) {
        ... Serialize object ...
        Octave_map all_props = go.get_properties().get(true).map_value();
        for (Octave_map::iterator it = all_props.begin(); it !=
all_props.end(); ++it) {
                ... Serialize property ...
        }
}

Any feedback would be much appreciated.

Thanks.

Ryan
Reply | Threaded
Open this post in threaded view
|

Re: base_graphics_backend

Michael Goffioul
On Tue, Sep 9, 2008 at 6:45 AM, Ryan Rusaw <[hidden email]> wrote:

> Michael,
>
> I've implemented a implement a subclass of base_graphics_backend that
> implements a simple wire protocol with JSON-based data serialization.
> I've just encountered a few issues
>
> 1. A property_changed event is never fired for
> base_properties::children. Is this the expected behavior? I've
> resorted to keeping track of children
> myself on the plotting end of the ipc socket, as I never know when the
> children have been updated.

Yes. The "children" property is not yet a real property so
it does not fire any event. This should be changed.

> 2. I seem to get spurious object deletions and incomplete handle reassignments.
>
> octave:1> autoload("__init_octave_eclipse__",
> file_in_loadpath("octave_eclipse_backend.oct"))
> octave:2> backend ("octave_eclipse")
> octave:3> figure
> octave:4> plot(0:.1:10,cos(0:.1:10))
> octave:5> exit
> error: graphics_handle::free: invalid object -6.19755
> error: graphics_handle::free: invalid object -7.33522
> error: graphics_handle::free: invalid object -8.76823
> error: graphics_handle::free: invalid object -9.27777

Can you debug octave to see the backtrace when you get
this error?

> It seems to create the figure and axes correctly, but then creates
> extra text objects ([xyz]label + title) just to delete them again.
> Could this be a byproduct of iterating through all the properties of
> an object during the object_created function call?

Yes. When an axes object is first created, its "title" and
"[xyz]label" properties are empty. Accessing them will trigger
the creation of a text object (whose handle is then stored in
the corresponding property). However, if I read your log correctly,
it seems the text objects are deleted before the line and hggroup
objects are created. I'm wondering why this happens. Could you
also break execution when the first text object is destroyed and
produce a backtrace?

Michael.
Reply | Threaded
Open this post in threaded view
|

Re: base_graphics_backend

David Bateman-3
Michael Goffioul wrote:

> Yes. When an axes object is first created, its "title" and
> "[xyz]label" properties are empty. Accessing them will trigger
> the creation of a text object (whose handle is then stored in
> the corresponding property). However, if I read your log correctly,
> it seems the text objects are deleted before the line and hggroup
> objects are created. I'm wondering why this happens. Could you
> also break execution when the first text object is destroyed and
> produce a backtrace?
>
>  

I'm currently also having issues with callbacks and the title,
[xyz]label properties of the axes objects in that I see  them ending up
with the wrong object type (ie not a "text" object). Trying to debug it,
but it seems to be quite bizarre.

D.

--
David Bateman                                [hidden email]
Motorola Labs - Paris                        +33 1 69 35 48 04 (Ph)
Parc Les Algorithmes, Commune de St Aubin    +33 6 72 01 06 33 (Mob)
91193 Gif-Sur-Yvette FRANCE                  +33 1 69 35 77 01 (Fax)

The information contained in this communication has been classified as:

[x] General Business Information
[ ] Motorola Internal Use Only
[ ] Motorola Confidential Proprietary

Reply | Threaded
Open this post in threaded view
|

Re: base_graphics_backend

Ryan Rusaw
On Tue, Sep 9, 2008 at 4:32 AM, David Bateman
<[hidden email]> wrote:
>
> I'm currently also having issues with callbacks and the title, [xyz]label
> properties of the axes objects in that I see  them ending up with the wrong
> object type (ie not a "text" object). Trying to debug it, but it seems to be
> quite bizarre.

That corresponds to the behaviour I'm seeing.

{"payload":{"objectCreated":{"object":{"properties":[{"key":"__myhandle__","value":{"double_value":-8.768229594562095}},{"key":"type","value":{"string_value":"text"}}]}}}}

{"payload":{"objectDeleted":{"object_id":-8.768229594562095}}}

{"payload":{"objectCreated":{"object":{"properties":[{"key":"__myhandle__","value":{"double_value":-8.768229594562095}},{"key":"type","value":{"string_value":"line"}}]}}}}

But the ylabel property of the axes isn't updated and still contains
-8.768229594562095.

Ryan
Reply | Threaded
Open this post in threaded view
|

Re: base_graphics_backend

Ryan Rusaw
In reply to this post by Michael Goffioul
On Tue, Sep 9, 2008 at 4:24 AM, Michael Goffioul
<[hidden email]> wrote:
>
> Yes. The "children" property is not yet a real property so
> it does not fire any event. This should be changed.
>

Ok. I just wasn't sure.

>
> Can you debug octave to see the backtrace when you get
> this error?
>

I'll have a look when I get home from work.

> Yes. When an axes object is first created, its "title" and
> "[xyz]label" properties are empty. Accessing them will trigger
> the creation of a text object (whose handle is then stored in
> the corresponding property). However, if I read your log correctly,
> it seems the text objects are deleted before the line and hggroup
> objects are created. I'm wondering why this happens. Could you
> also break execution when the first text object is destroyed and
> produce a backtrace?

Sure thing.

Ryan
Reply | Threaded
Open this post in threaded view
|

Re: base_graphics_backend

John W. Eaton-6
In reply to this post by David Bateman-3
On  9-Sep-2008, David Bateman wrote:

| Michael Goffioul wrote:
| > Yes. When an axes object is first created, its "title" and
| > "[xyz]label" properties are empty. Accessing them will trigger
| > the creation of a text object (whose handle is then stored in
| > the corresponding property). However, if I read your log correctly,
| > it seems the text objects are deleted before the line and hggroup
| > objects are created. I'm wondering why this happens. Could you
| > also break execution when the first text object is destroyed and
| > produce a backtrace?
| >
| >  
|
| I'm currently also having issues with callbacks and the title,
| [xyz]label properties of the axes objects in that I see  them ending up
| with the wrong object type (ie not a "text" object). Trying to debug it,
| but it seems to be quite bizarre.

Do you have a simple example that demonstrates the problem?

jwe
Reply | Threaded
Open this post in threaded view
|

Re: base_graphics_backend

David Bateman-6
John W. Eaton wrote:

> On  9-Sep-2008, David Bateman wrote:
>
> | Michael Goffioul wrote:
> | > Yes. When an axes object is first created, its "title" and
> | > "[xyz]label" properties are empty. Accessing them will trigger
> | > the creation of a text object (whose handle is then stored in
> | > the corresponding property). However, if I read your log correctly,
> | > it seems the text objects are deleted before the line and hggroup
> | > objects are created. I'm wondering why this happens. Could you
> | > also break execution when the first text object is destroyed and
> | > produce a backtrace?
> | >
> | >  
> |
> | I'm currently also having issues with callbacks and the title,
> | [xyz]label properties of the axes objects in that I see  them ending up
> | with the wrong object type (ie not a "text" object). Trying to debug it,
> | but it seems to be quite bizarre.
>
> Do you have a simple example that demonstrates the problem?
>
> jwe
>

Sorry no short example as the issue seems to be related to an
interaction between the existing code and my use of callbacks in a
plotyy/colorbar changeset I'm working on. I'll send the changeset to
you, Michael and Ryan with an example offline.

D.
Reply | Threaded
Open this post in threaded view
|

Re: base_graphics_backend

Michael Goffioul
In reply to this post by Ryan Rusaw
On Tue, Sep 9, 2008 at 5:57 PM, Ryan Rusaw <[hidden email]> wrote:

> On Tue, Sep 9, 2008 at 4:32 AM, David Bateman
> <[hidden email]> wrote:
>>
>> I'm currently also having issues with callbacks and the title, [xyz]label
>> properties of the axes objects in that I see  them ending up with the wrong
>> object type (ie not a "text" object). Trying to debug it, but it seems to be
>> quite bizarre.
>
> That corresponds to the behaviour I'm seeing.
>
> {"payload":{"objectCreated":{"object":{"properties":[{"key":"__myhandle__","value":{"double_value":-8.768229594562095}},{"key":"type","value":{"string_value":"text"}}]}}}}
>
> {"payload":{"objectDeleted":{"object_id":-8.768229594562095}}}
>
> {"payload":{"objectCreated":{"object":{"properties":[{"key":"__myhandle__","value":{"double_value":-8.768229594562095}},{"key":"type","value":{"string_value":"line"}}]}}}}
>
> But the ylabel property of the axes isn't updated and still contains
> -8.768229594562095.

The question here is why is the text object destroyed. The fact that the
line object has the same handle is because the graphics code recycle
handle values instead of generating a new ones. Maybe this should be
avoided.

Michael.
Reply | Threaded
Open this post in threaded view
|

Re: base_graphics_backend

John W. Eaton-6
On  9-Sep-2008, Michael Goffioul wrote:

| The question here is why is the text object destroyed. The fact that the
| line object has the same handle is because the graphics code recycle
| handle values instead of generating a new ones. Maybe this should be
| avoided.

I don't see a problem with recycling old handle values.  The handle
should be recycled only if it has been freed, and that should only
happen if there are no longer any uses for it.  Or are you saying that
because someone can do

  h = line ();
  close all;
  get (h)

and the get call will fail, that we should not recycle handle values?
I guess I'm a bit confused about what the problem is.

jwe

Reply | Threaded
Open this post in threaded view
|

Re: base_graphics_backend

Ryan Rusaw
In reply to this post by Ryan Rusaw
On Tue, Sep 9, 2008 at 10:02 AM, Ryan Rusaw <[hidden email]> wrote:

> On Tue, Sep 9, 2008 at 4:24 AM, Michael Goffioul
> <[hidden email]> wrote:
>>
>> Yes. The "children" property is not yet a real property so
>> it does not fire any event. This should be changed.
>>
>
> Ok. I just wasn't sure.
>
>>
>> Can you debug octave to see the backtrace when you get
>> this error?
>>
>
> I'll have a look when I get home from work.
>

#0  gh_manager::do_free (this=0x8355360, h=@0xbfab9490) at
../../src/graphics.cc:1313
#1  0xb74c2caa in axes::properties::delete_children (this=0x84dda08)
at ./graphics.h:8565
#2  0xb7533213 in ~axes (this=0x84dda00) at ./graphics.h:5259
#3  0xb74c2a47 in gh_manager::do_free (this=0x8355360, h=@0xbfab9560)
at ./graphics.h:2190
#4  0xb74c2bd1 in base_properties::delete_children (this=0x84945e0) at
./graphics.h:8565
#5  0xb7532cd3 in ~figure (this=0x84945d8) at ./graphics.h:3373
#6  0xb74f8778 in F__go_execute_callback__ (args=@0x8654f50) at
./graphics.h:2190
#7  0xb780f8ec in octave_builtin::do_multi_index_op (this=0x807afc4,
nargout=0, args=@0x8654f50)
    at ../../src/ov-builtin.cc:107
#8  0xb78100b6 in octave_builtin::subsref (this=0x807afc4,
type=@0x8650afc, idx=@0xbfab996c, nargout=0)
    at ../../src/ov-builtin.cc:55
#9  0xb77b0ce8 in octave_value::subsref (this=0xbfab9994,
type=@0x8650afc, idx=@0xbfab996c, nargout=0)
    at ../../src/ov.cc:1038
#10 0xb79615f1 in tree_index_expression::rvalue (this=0x8650ad8,
nargout=0) at ../../src/pt-idx.cc:375
#11 0xb798664b in tree_statement::eval (this=0x8650b90, silent=false,
nargout=0, in_function_or_script_body=false)
    at ../../src/pt-stmt.cc:125
#12 0xb7986db3 in tree_statement_list::eval (this=0x86507d0,
silent=100, nargout=0) at ../../src/pt-stmt.cc:186
#13 0xb7970b49 in tree_simple_for_command::do_for_loop_once
(this=0x8650810, ult=@0xbfaba018, rhs=@0xbfaba30c,
    quit=@0xbfaba316) at ../../src/pt-loop.cc:207
#14 0xb796714d in tree_simple_for_command::eval (this=0x8650810) at
../../src/pt-loop.cc:354
#15 0xb7986484 in tree_statement::eval (this=0x8650b68, silent=false,
nargout=0, in_function_or_script_body=true)
    at ../../src/pt-stmt.cc:100
#16 0xb7986db3 in tree_statement_list::eval (this=0x86448f0,
silent=100, nargout=0) at ../../src/pt-stmt.cc:186
---Type <return> to continue, or q <return> to quit---
#17 0xb7819b71 in octave_user_function::do_multi_index_op
(this=0x8113d08, nargout=0, args=@0x8648818)
    at ../../src/ov-usr-fcn.cc:438
#18 0xb7818af1 in octave_user_function::subsref (this=0x8113d08,
type=@0x8653a04, idx=@0xbfaba82c, nargout=0)
    at ../../src/ov-usr-fcn.cc:311
#19 0xb77b0ce8 in octave_value::subsref (this=0xbfaba854,
type=@0x8653a04, idx=@0xbfaba82c, nargout=0)
    at ../../src/ov.cc:1038
#20 0xb79615f1 in tree_index_expression::rvalue (this=0x86539e0,
nargout=0) at ../../src/pt-idx.cc:375
#21 0xb798664b in tree_statement::eval (this=0x8653a70, silent=false,
nargout=0, in_function_or_script_body=false)
    at ../../src/pt-stmt.cc:125
#22 0xb7986db3 in tree_statement_list::eval (this=0x8653b08,
silent=100, nargout=0) at ../../src/pt-stmt.cc:186
#23 0xb7966042 in tree_while_command::eval (this=0x8653a98) at
../../src/pt-loop.cc:101
#24 0xb7986484 in tree_statement::eval (this=0x8653ac0, silent=false,
nargout=0, in_function_or_script_body=true)
    at ../../src/pt-stmt.cc:100
#25 0xb7986db3 in tree_statement_list::eval (this=0x8653b28,
silent=100, nargout=0) at ../../src/pt-stmt.cc:186
#26 0xb7819b71 in octave_user_function::do_multi_index_op
(this=0x8113c5c, nargout=0, args=@0x86423f0)
    at ../../src/ov-usr-fcn.cc:438
#27 0xb7818af1 in octave_user_function::subsref (this=0x8113c5c,
type=@0x864edb4, idx=@0xbfabaecc, nargout=0)
    at ../../src/ov-usr-fcn.cc:311
#28 0xb77b0ce8 in octave_value::subsref (this=0xbfabaef4,
type=@0x864edb4, idx=@0xbfabaecc, nargout=0)
    at ../../src/ov.cc:1038
#29 0xb79615f1 in tree_index_expression::rvalue (this=0x864ed90,
nargout=0) at ../../src/pt-idx.cc:375
#30 0xb798664b in tree_statement::eval (this=0x864f428, silent=false,
nargout=0, in_function_or_script_body=false)
    at ../../src/pt-stmt.cc:125
---Type <return> to continue, or q <return> to quit---
#31 0xb7986db3 in tree_statement_list::eval (this=0x864f4b0,
silent=100, nargout=0) at ../../src/pt-stmt.cc:186
#32 0xb79840fb in tree_if_clause::eval (this=0x864f440) at
../../src/pt-select.cc:54
#33 0xb798422d in tree_if_command_list::eval (this=0x864b400) at
../../src/pt-select.cc:86
#34 0xb7984264 in tree_if_command::eval (this=0x864fb18) at
../../src/pt-select.cc:126
#35 0xb7986484 in tree_statement::eval (this=0x864faa8, silent=false,
nargout=0, in_function_or_script_body=true)
    at ../../src/pt-stmt.cc:100
#36 0xb7986db3 in tree_statement_list::eval (this=0x86448f0,
silent=100, nargout=0) at ../../src/pt-stmt.cc:186
#37 0xb7819b71 in octave_user_function::do_multi_index_op
(this=0x8113d08, nargout=0, args=@0x8654198)
    at ../../src/ov-usr-fcn.cc:438
#38 0xb7818af1 in octave_user_function::subsref (this=0x8113d08,
type=@0x8646814, idx=@0xbfabb58c, nargout=0)
    at ../../src/ov-usr-fcn.cc:311
#39 0xb77b0ce8 in octave_value::subsref (this=0xbfabb5b4,
type=@0x8646814, idx=@0xbfabb58c, nargout=0)
    at ../../src/ov.cc:1038
#40 0xb79615f1 in tree_index_expression::rvalue (this=0x86467f0,
nargout=0) at ../../src/pt-idx.cc:375
#41 0xb798664b in tree_statement::eval (this=0x86462e8, silent=false,
nargout=0, in_function_or_script_body=true)
    at ../../src/pt-stmt.cc:125
#42 0xb7986db3 in tree_statement_list::eval (this=0x846acf8,
silent=100, nargout=0) at ../../src/pt-stmt.cc:186
#43 0xb7819b71 in octave_user_function::do_multi_index_op
(this=0x8113bb0, nargout=0, args=@0xbfabb9c4)
    at ../../src/ov-usr-fcn.cc:438
#44 0xb77b0329 in octave_value::do_multi_index_op (this=0xbfabb964,
nargout=0, idx=@0xbfabb9c4) at ../../src/ov.cc:1076
#45 0xb767c6e3 in feval (name=@0xbfabb9e8, args=@0xbfabb9c4,
nargout=0) at ../../src/parse.y:3585
#46 0xb76e6311 in do_octave_atexit () at ../../src/toplev.cc:957
#47 0xb76e674f in clean_up_and_exit (retval=0) at ../../src/toplev.cc:624
---Type <return> to continue, or q <return> to quit---
#48 0xb76e6868 in Fquit (args=@0xbfabbb98, nargout=0) at ../../src/toplev.cc:656
#49 0xb780f8ec in octave_builtin::do_multi_index_op (this=0x8167c0c,
nargout=0, args=@0xbfabbb98)
    at ../../src/ov-builtin.cc:107
#50 0xb77b0329 in octave_value::do_multi_index_op (this=0xbfabbbf4,
nargout=0, idx=@0xbfabbb98) at ../../src/ov.cc:1076
#51 0xb7959fc3 in tree_identifier::rvalue (this=0x84a23a0, nargout=0)
at ../../src/pt-id.cc:86
#52 0xb798664b in tree_statement::eval (this=0x846c280, silent=false,
nargout=0, in_function_or_script_body=false)
    at ../../src/pt-stmt.cc:125
#53 0xb7986db3 in tree_statement_list::eval (this=0x82b4208,
silent=100, nargout=0) at ../../src/pt-stmt.cc:186
#54 0xb76e5dd5 in main_loop () at ../../src/toplev.cc:557
#55 0xb766b276 in octave_main (argc=1, argv=0xbfabbfa4, embedded=0) at
../../src/octave.cc:852
#56 0x0804878a in main (argc=1, argv=0x84f2c98) at ../../src/main.c:35

>> Yes. When an axes object is first created, its "title" and
>> "[xyz]label" properties are empty. Accessing them will trigger
>> the creation of a text object (whose handle is then stored in
>> the corresponding property). However, if I read your log correctly,
>> it seems the text objects are deleted before the line and hggroup
>> objects are created. I'm wondering why this happens. Could you
>> also break execution when the first text object is destroyed and
>> produce a backtrace?
>
> Sure thing.
>

#0  octave_eclipse_backend::object_destroyed (this=0x81bf838,
go=@0x8508768) at octave_eclipse_backend.cc:609
#1  0xb74c2a1e in gh_manager::do_free (this=0x8355360, h=@0xbfaba1e0)
at ./graphics.h:1528
#2  0xb74c2caa in axes::properties::delete_children (this=0x84dda08)
at ./graphics.h:8565
#3  0xb74e2c47 in axes::properties::set_defaults (this=0x84dda08,
obj=@0x84dda00, mode=@0xbfaba94c)
    at ../../src/graphics.cc:2270
#4  0xb753463b in axes::set_defaults (this=0x84dda00,
mode=@0xbfaba94c) at ./graphics.h:5288
#5  0xb74fbb07 in F__go_axes_init__ (args=@0x850bf40) at ./graphics.h:2209
#6  0xb780f8ec in octave_builtin::do_multi_index_op (this=0x807af70,
nargout=0, args=@0x850bf40)
    at ../../src/ov-builtin.cc:107
#7  0xb78100b6 in octave_builtin::subsref (this=0x807af70,
type=@0x84fca54, idx=@0xbfabac2c, nargout=0)
    at ../../src/ov-builtin.cc:55
#8  0xb77b0ce8 in octave_value::subsref (this=0xbfabac54,
type=@0x84fca54, idx=@0xbfabac2c, nargout=0)
    at ../../src/ov.cc:1038
#9  0xb79615f1 in tree_index_expression::rvalue (this=0x84fca30,
nargout=0) at ../../src/pt-idx.cc:375
#10 0xb798664b in tree_statement::eval (this=0x84fc468, silent=false,
nargout=0, in_function_or_script_body=false)
    at ../../src/pt-stmt.cc:125
#11 0xb7986db3 in tree_statement_list::eval (this=0x84fc758,
silent=104, nargout=0) at ../../src/pt-stmt.cc:186
#12 0xb798549b in tree_switch_case::eval (this=0x84fcc58,
val=@0xbfabae08) at ../../src/pt-select.cc:222
#13 0xb79855d4 in tree_switch_case_list::eval (this=0x84fc340,
val=@0xbfabae08) at ../../src/pt-select.cc:254
#14 0xb7985635 in tree_switch_command::eval (this=0x84fd5a0) at
../../src/pt-select.cc:299
#15 0xb7986484 in tree_statement::eval (this=0x84fd338, silent=false,
nargout=0, in_function_or_script_body=false)
    at ../../src/pt-stmt.cc:100
#16 0xb7986db3 in tree_statement_list::eval (this=0x84dd960,
silent=104, nargout=0) at ../../src/pt-stmt.cc:186
#17 0xb79840fb in tree_if_clause::eval (this=0x84fd678) at
../../src/pt-select.cc:54
#18 0xb798422d in tree_if_command_list::eval (this=0x84fd688) at
../../src/pt-select.cc:86
#19 0xb7984264 in tree_if_command::eval (this=0x84fdd48) at
../../src/pt-select.cc:126
#20 0xb7986484 in tree_statement::eval (this=0x84fd4f0, silent=false,
nargout=0, in_function_or_script_body=true)
    at ../../src/pt-stmt.cc:100
#21 0xb7986db3 in tree_statement_list::eval (this=0x84fdd68,
silent=104, nargout=0) at ../../src/pt-stmt.cc:186
#22 0xb7819b71 in octave_user_function::do_multi_index_op
(this=0x8113044, nargout=0, args=@0x84f5fd0)
    at ../../src/ov-usr-fcn.cc:438
#23 0xb7818af1 in octave_user_function::subsref (this=0x8113044,
type=@0x84a1e64, idx=@0xbfabb49c, nargout=0)
    at ../../src/ov-usr-fcn.cc:311
#24 0xb77b0ce8 in octave_value::subsref (this=0xbfabb4c4,
type=@0x84a1e64, idx=@0xbfabb49c, nargout=0)
    at ../../src/ov.cc:1038
#25 0xb79615f1 in tree_index_expression::rvalue (this=0x84a1e40,
nargout=0) at ../../src/pt-idx.cc:375
#26 0xb798664b in tree_statement::eval (this=0x84b3530, silent=false,
nargout=0, in_function_or_script_body=false)
    at ../../src/pt-stmt.cc:125
#27 0xb7986db3 in tree_statement_list::eval (this=0x84a1b78,
silent=104, nargout=0) at ../../src/pt-stmt.cc:186
#28 0xb7952f6d in tree_unwind_protect_command::eval (this=0x84b41c0)
at ../../src/pt-except.cc:250
#29 0xb7986484 in tree_statement::eval (this=0x84b4670, silent=false,
nargout=0, in_function_or_script_body=true)
    at ../../src/pt-stmt.cc:100
#30 0xb7986db3 in tree_statement_list::eval (this=0x84b11b0,
silent=104, nargout=0) at ../../src/pt-stmt.cc:186
#31 0xb7819b71 in octave_user_function::do_multi_index_op
(this=0x8112ae4, nargout=0, args=@0x84b5140)
    at ../../src/ov-usr-fcn.cc:438
#32 0xb7818af1 in octave_user_function::subsref (this=0x8112ae4,
type=@0x84aeef4, idx=@0xbfabbbcc, nargout=0)
    at ../../src/ov-usr-fcn.cc:311
#33 0xb77b0ce8 in octave_value::subsref (this=0xbfabbbf4,
type=@0x84aeef4, idx=@0xbfabbbcc, nargout=0)
    at ../../src/ov.cc:1038
#34 0xb79615f1 in tree_index_expression::rvalue (this=0x84aeed0,
nargout=0) at ../../src/pt-idx.cc:375
#35 0xb798664b in tree_statement::eval (this=0x84717a8, silent=false,
nargout=0, in_function_or_script_body=false)
    at ../../src/pt-stmt.cc:125
#36 0xb7986db3 in tree_statement_list::eval (this=0x84a1f60,
silent=104, nargout=0) at ../../src/pt-stmt.cc:186
#37 0xb76e5dd5 in main_loop () at ../../src/toplev.cc:557
#38 0xb766b276 in octave_main (argc=1, argv=0xbfabbfa4, embedded=0) at
../../src/octave.cc:852
#39 0x0804878a in main (argc=1, argv=0x832b4c8) at ../../src/main.c:35


> Ryan
>
Reply | Threaded
Open this post in threaded view
|

Re: base_graphics_backend

Michael Goffioul
In reply to this post by John W. Eaton-6
On Tue, Sep 9, 2008 at 9:47 PM, John W. Eaton <[hidden email]> wrote:

> I don't see a problem with recycling old handle values.  The handle
> should be recycled only if it has been freed, and that should only
> happen if there are no longer any uses for it.  Or are you saying that
> because someone can do
>
>  h = line ();
>  close all;
>  get (h)
>
> and the get call will fail, that we should not recycle handle values?
> I guess I'm a bit confused about what the problem is.

Recycling handles may have some undesired side effects. For
instance consider this piece of code:

h1 = plot(rand(1,10))
close
h2 = plot(rand(1,10))
close
h3 = plot(rand(1,10))
get(h2)

With the current handle recycling, the "get(h2)" call does not
produce any error and returns the properties of h3. The question
is then: what should be the expected behavior?

But concerning the problem reported by Ryan, the actual
problem is that the text objects (title and labels) of the axes
are destroyed, but the axes object does not know about it,
such that the stored handles point to invalid objects. This
should not happen and I'm wondering why the text objects are
destroyed in the first place.

Ryan: could you break you code in your backend's object_destroyed
method to see where it does come from?

Michael.
Reply | Threaded
Open this post in threaded view
|

Re: base_graphics_backend

Michael Goffioul
On Wed, Sep 10, 2008 at 9:45 AM, Michael Goffioul
<[hidden email]> wrote:
> Ryan: could you break you code in your backend's object_destroyed
> method to see where it does come from?

Sorry, I didn't notice the second backtrace in your other mail. I think
I see the problem (or at least one): in set_defaults, the title and labels
are reassigned without taking care of freeing them, so we're leaking
handles.

Michael.
Reply | Threaded
Open this post in threaded view
|

Re: base_graphics_backend

Michael Goffioul
In reply to this post by Ryan Rusaw
There's something strange in this backtrace: when delete_children()
is called from axes::properties::set_defaults(), normally the title
and labels contains invalid handles, such that the call to free()
(from delete_children()) should not trigger any object_destroyed()
in the backend. It seems that between "title = graphics_handle ()"
and "delete_children ()" (in axes::properties::set_defaults), the handle
for the title is recreated. Ryan, could you track this down?

Michael.


On Wed, Sep 10, 2008 at 6:56 AM, Ryan Rusaw <[hidden email]> wrote:

>>> Yes. When an axes object is first created, its "title" and
>>> "[xyz]label" properties are empty. Accessing them will trigger
>>> the creation of a text object (whose handle is then stored in
>>> the corresponding property). However, if I read your log correctly,
>>> it seems the text objects are deleted before the line and hggroup
>>> objects are created. I'm wondering why this happens. Could you
>>> also break execution when the first text object is destroyed and
>>> produce a backtrace?
>>
>> Sure thing.
>>
>
> #0  octave_eclipse_backend::object_destroyed (this=0x81bf838,
> go=@0x8508768) at octave_eclipse_backend.cc:609
> #1  0xb74c2a1e in gh_manager::do_free (this=0x8355360, h=@0xbfaba1e0)
> at ./graphics.h:1528
> #2  0xb74c2caa in axes::properties::delete_children (this=0x84dda08)
> at ./graphics.h:8565
> #3  0xb74e2c47 in axes::properties::set_defaults (this=0x84dda08,
> obj=@0x84dda00, mode=@0xbfaba94c)
>    at ../../src/graphics.cc:2270
> #4  0xb753463b in axes::set_defaults (this=0x84dda00,
> mode=@0xbfaba94c) at ./graphics.h:5288
> #5  0xb74fbb07 in F__go_axes_init__ (args=@0x850bf40) at ./graphics.h:2209
> #6  0xb780f8ec in octave_builtin::do_multi_index_op (this=0x807af70,
> nargout=0, args=@0x850bf40)
>    at ../../src/ov-builtin.cc:107
> #7  0xb78100b6 in octave_builtin::subsref (this=0x807af70,
> type=@0x84fca54, idx=@0xbfabac2c, nargout=0)
>    at ../../src/ov-builtin.cc:55
> #8  0xb77b0ce8 in octave_value::subsref (this=0xbfabac54,
> type=@0x84fca54, idx=@0xbfabac2c, nargout=0)
>    at ../../src/ov.cc:1038
> #9  0xb79615f1 in tree_index_expression::rvalue (this=0x84fca30,
> nargout=0) at ../../src/pt-idx.cc:375
> #10 0xb798664b in tree_statement::eval (this=0x84fc468, silent=false,
> nargout=0, in_function_or_script_body=false)
>    at ../../src/pt-stmt.cc:125
> #11 0xb7986db3 in tree_statement_list::eval (this=0x84fc758,
> silent=104, nargout=0) at ../../src/pt-stmt.cc:186
> #12 0xb798549b in tree_switch_case::eval (this=0x84fcc58,
> val=@0xbfabae08) at ../../src/pt-select.cc:222
> #13 0xb79855d4 in tree_switch_case_list::eval (this=0x84fc340,
> val=@0xbfabae08) at ../../src/pt-select.cc:254
> #14 0xb7985635 in tree_switch_command::eval (this=0x84fd5a0) at
> ../../src/pt-select.cc:299
> #15 0xb7986484 in tree_statement::eval (this=0x84fd338, silent=false,
> nargout=0, in_function_or_script_body=false)
>    at ../../src/pt-stmt.cc:100
> #16 0xb7986db3 in tree_statement_list::eval (this=0x84dd960,
> silent=104, nargout=0) at ../../src/pt-stmt.cc:186
> #17 0xb79840fb in tree_if_clause::eval (this=0x84fd678) at
> ../../src/pt-select.cc:54
> #18 0xb798422d in tree_if_command_list::eval (this=0x84fd688) at
> ../../src/pt-select.cc:86
> #19 0xb7984264 in tree_if_command::eval (this=0x84fdd48) at
> ../../src/pt-select.cc:126
> #20 0xb7986484 in tree_statement::eval (this=0x84fd4f0, silent=false,
> nargout=0, in_function_or_script_body=true)
>    at ../../src/pt-stmt.cc:100
> #21 0xb7986db3 in tree_statement_list::eval (this=0x84fdd68,
> silent=104, nargout=0) at ../../src/pt-stmt.cc:186
> #22 0xb7819b71 in octave_user_function::do_multi_index_op
> (this=0x8113044, nargout=0, args=@0x84f5fd0)
>    at ../../src/ov-usr-fcn.cc:438
> #23 0xb7818af1 in octave_user_function::subsref (this=0x8113044,
> type=@0x84a1e64, idx=@0xbfabb49c, nargout=0)
>    at ../../src/ov-usr-fcn.cc:311
> #24 0xb77b0ce8 in octave_value::subsref (this=0xbfabb4c4,
> type=@0x84a1e64, idx=@0xbfabb49c, nargout=0)
>    at ../../src/ov.cc:1038
> #25 0xb79615f1 in tree_index_expression::rvalue (this=0x84a1e40,
> nargout=0) at ../../src/pt-idx.cc:375
> #26 0xb798664b in tree_statement::eval (this=0x84b3530, silent=false,
> nargout=0, in_function_or_script_body=false)
>    at ../../src/pt-stmt.cc:125
> #27 0xb7986db3 in tree_statement_list::eval (this=0x84a1b78,
> silent=104, nargout=0) at ../../src/pt-stmt.cc:186
> #28 0xb7952f6d in tree_unwind_protect_command::eval (this=0x84b41c0)
> at ../../src/pt-except.cc:250
> #29 0xb7986484 in tree_statement::eval (this=0x84b4670, silent=false,
> nargout=0, in_function_or_script_body=true)
>    at ../../src/pt-stmt.cc:100
> #30 0xb7986db3 in tree_statement_list::eval (this=0x84b11b0,
> silent=104, nargout=0) at ../../src/pt-stmt.cc:186
> #31 0xb7819b71 in octave_user_function::do_multi_index_op
> (this=0x8112ae4, nargout=0, args=@0x84b5140)
>    at ../../src/ov-usr-fcn.cc:438
> #32 0xb7818af1 in octave_user_function::subsref (this=0x8112ae4,
> type=@0x84aeef4, idx=@0xbfabbbcc, nargout=0)
>    at ../../src/ov-usr-fcn.cc:311
> #33 0xb77b0ce8 in octave_value::subsref (this=0xbfabbbf4,
> type=@0x84aeef4, idx=@0xbfabbbcc, nargout=0)
>    at ../../src/ov.cc:1038
> #34 0xb79615f1 in tree_index_expression::rvalue (this=0x84aeed0,
> nargout=0) at ../../src/pt-idx.cc:375
> #35 0xb798664b in tree_statement::eval (this=0x84717a8, silent=false,
> nargout=0, in_function_or_script_body=false)
>    at ../../src/pt-stmt.cc:125
> #36 0xb7986db3 in tree_statement_list::eval (this=0x84a1f60,
> silent=104, nargout=0) at ../../src/pt-stmt.cc:186
> #37 0xb76e5dd5 in main_loop () at ../../src/toplev.cc:557
> #38 0xb766b276 in octave_main (argc=1, argv=0xbfabbfa4, embedded=0) at
> ../../src/octave.cc:852
> #39 0x0804878a in main (argc=1, argv=0x832b4c8) at ../../src/main.c:35
>
>
>> Ryan
>>
>
Reply | Threaded
Open this post in threaded view
|

Re: base_graphics_backend

Ryan Rusaw
On Wed, Sep 10, 2008 at 2:00 AM, Michael Goffioul
<[hidden email]> wrote:

> There's something strange in this backtrace: when delete_children()
> is called from axes::properties::set_defaults(), normally the title
> and labels contains invalid handles, such that the call to free()
> (from delete_children()) should not trigger any object_destroyed()
> in the backend. It seems that between "title = graphics_handle ()"
> and "delete_children ()" (in axes::properties::set_defaults), the handle
> for the title is recreated. Ryan, could you track this down?
>
> Michael.
>

I think the problem is in my object_created() method, I iterate
through all the values returned by go.get(true).map_value() which in
turn causes the label objects to be created and appropriate
handle_property of the axes to be updated. Eventually
axes::properties::set_defaults is called on the created axes,
assigning new handles to the label properties. This is followed
shortly by delete_children() which immediately deletes the new
handles, and fires off the object_destroyed methods.

I'm curious as to where the extra object_created calls are coming from
though, but alas it is almost 2:30 AM here,  I'll look into this
further tomorrow after I catch some sleep.

Ryan
Reply | Threaded
Open this post in threaded view
|

Re: base_graphics_backend

Ryan Rusaw
In reply to this post by Michael Goffioul
On Wed, Sep 10, 2008 at 2:00 AM, Michael Goffioul
<[hidden email]> wrote:

> There's something strange in this backtrace: when delete_children()
> is called from axes::properties::set_defaults(), normally the title
> and labels contains invalid handles, such that the call to free()
> (from delete_children()) should not trigger any object_destroyed()
> in the backend. It seems that between "title = graphics_handle ()"
> and "delete_children ()" (in axes::properties::set_defaults), the handle
> for the title is recreated. Ryan, could you track this down?
>
> Michael.
>

#0  octave_eclipse_backend::object_created (this=0x84634c0, go=@0xbfc22aa0)
    at octave_eclipse_backend.cc:578
#1  0xb7542571 in gh_manager::do_make_graphics_handle (this=0x81c9c08,
    go_name=@0xbfc22b00, p=@0x84de5ec, do_createfcn=true) at ./graphics.h:1519
#2  0xb7546f43 in axes::properties::get_title (this=0x84de100)
    at ./graphics.h:8584
#3  0xb754be6e in axes::properties::get (this=0x84de100, pname=@0xbfc232ec)
    at ./graphics-props.cc:1390
#4  0xb51dce2b in octave_eclipse_backend::property_changed (this=0x84634c0,
    go=@0xbfc23348, id=3001) at octave_eclipse_backend.cc:525
#5  0xb7526946 in base_property::set (this=0x84de720, v=@0xbfc238d0,
    do_run=true) at ./graphics.h:1512
#6  0xb754705d in axes::properties::set_defaults (this=0x84de100,
    obj=@0x84de0f8, mode=@0xbfc23aac) at ./graphics.h:1125
#7  0xb759b63b in axes::set_defaults (this=0x84de0f8, mode=@0xbfc23aac)
    at ./graphics.h:5288
#8  0xb7562b07 in F__go_axes_init__ (args=@0x8511f30) at ./graphics.h:2209

It looks like when set_defaults assigns a graphics handle to the title
property, it calls property_changed on the title. My backend then
attempts to get the property value from the object which results in
another text object being created.

And now to sleep.

Ryan
Reply | Threaded
Open this post in threaded view
|

Re: base_graphics_backend

David Bateman-3
In reply to this post by Michael Goffioul
Michael Goffioul wrote:

> On Wed, Sep 10, 2008 at 9:45 AM, Michael Goffioul
> <[hidden email]> wrote:
>  
>> Ryan: could you break you code in your backend's object_destroyed
>> method to see where it does come from?
>>    
>
> Sorry, I didn't notice the second backtrace in your other mail. I think
> I see the problem (or at least one): in set_defaults, the title and labels
> are reassigned without taking care of freeing them, so we're leaking
> handles.
>
> Michael.
>
>  
Yes this was part of the patch I sent to you offline

@@ -2158,7 +2171,9 @@ axes::properties::set_defaults (base_gra
 axes::properties::set_defaults (base_graphics_object& obj,
                 const std::string& mode)
 {
+  gh_manager::free (title.handle_value ());
   title = graphics_handle ();
+
   box = "on";
   key = "off";
   keybox = "off";
@@ -2182,9 +2197,14 @@ axes::properties::set_defaults (base_gra
   ylimmode = "auto";
   zlimmode = "auto";
   climmode = "auto";
+
+  gh_manager::free (xlabel.handle_value ());
+  gh_manager::free (ylabel.handle_value ());
+  gh_manager::free (zlabel.handle_value ());
   xlabel = graphics_handle ();
   ylabel = graphics_handle ();
   zlabel = graphics_handle ();
+
   xgrid = "off";
   ygrid = "off";
   zgrid = "off";


Unfortunately what this does is that instead of having the error that
the title [xyz]label objects point to the wrong object type, they end up
pointing to an invalid object. I still have no idea why.

D.

--
David Bateman                                [hidden email]
Motorola Labs - Paris                        +33 1 69 35 48 04 (Ph)
Parc Les Algorithmes, Commune de St Aubin    +33 6 72 01 06 33 (Mob)
91193 Gif-Sur-Yvette FRANCE                  +33 1 69 35 77 01 (Fax)

The information contained in this communication has been classified as:

[x] General Business Information
[ ] Motorola Internal Use Only
[ ] Motorola Confidential Proprietary

Reply | Threaded
Open this post in threaded view
|

Re: base_graphics_backend

Michael Goffioul
On Wed, Sep 10, 2008 at 1:51 PM, David Bateman
<[hidden email]> wrote:

> Yes this was part of the patch I sent to you offline
>
> @@ -2158,7 +2171,9 @@ axes::properties::set_defaults (base_gra
> axes::properties::set_defaults (base_graphics_object& obj,
>                const std::string& mode)
> {
> +  gh_manager::free (title.handle_value ());
>  title = graphics_handle ();
> +
>  box = "on";
>  key = "off";
>  keybox = "off";
> @@ -2182,9 +2197,14 @@ axes::properties::set_defaults (base_gra
>  ylimmode = "auto";
>  zlimmode = "auto";
>  climmode = "auto";
> +
> +  gh_manager::free (xlabel.handle_value ());
> +  gh_manager::free (ylabel.handle_value ());
> +  gh_manager::free (zlabel.handle_value ());
>  xlabel = graphics_handle ();
>  ylabel = graphics_handle ();
>  zlabel = graphics_handle ();
> +
>  xgrid = "off";
>  ygrid = "off";
>  zgrid = "off";
>
>
> Unfortunately what this does is that instead of having the error that the
> title [xyz]label objects point to the wrong object type, they end up
> pointing to an invalid object. I still have no idea why.

Sorry, I missed that. Can you remind me where this is a problem?

Michael.