GNOME.org
 

Gtkmm-forge digest, Vol 1 #1129 - 8 msgs

Send Gtkmm-forge mailing list submissions to
	gtkmm-forge lists sourceforge net

To subscribe or unsubscribe via the World Wide Web, visit
	https://lists.sourceforge.net/lists/listinfo/gtkmm-forge
or, via email, send a message with subject or body 'help' to
	gtkmm-forge-request lists sourceforge net

You can reach the person managing the list at
	gtkmm-forge-admin lists sourceforge net

When replying, please edit your Subject line so it is more specific
than "Re: Contents of Gtkmm-forge digest..."


gtkmm-forge is the mailing list that receives gtkmm bug reports from bugzilla.  A daily digest is sent to gtkmm-main, to encourage people to help fixing the bugs. Do not try to unsubscribe gtkmm-forge from gtkmm-list.


Today's Topics:

   1. [Bug 339791] Gtk::Menu crash with child (gtkmm (bugzilla.gnome.org))
   2. [Bug 339791] Gtk::Menu crash with child (gtkmm (bugzilla.gnome.org))
   3. [Bug 339791] Gtk::Menu crash with child (gtkmm (bugzilla.gnome.org))
   4. [Bug 341895] gtkmm 2.8.6/2.8.7 are utterly hosed (gtkmm (bugzilla.gnome.org))
   5. [Bug 341895] gtkmm 2.8.6/2.8.7 are utterly hosed (gtkmm (bugzilla.gnome.org))
   6. [Bug 341895] gtkmm 2.8.6/2.8.7 are utterly hosed (gtkmm (bugzilla.gnome.org))
   7. [Bug 341895] gtkmm 2.8.6/2.8.7 are utterly hosed (gtkmm (bugzilla.gnome.org))
   8. [Bug 341895] gtkmm 2.8.6/2.8.7 are utterly hosed (gtkmm (bugzilla.gnome.org))

--__--__--

Message: 1
To: gtkmm-forge lists sourceforge net
From: "gtkmm (bugzilla.gnome.org)" <bugzilla-daemon bugzilla gnome org>
Date: Wed, 17 May 2006 09:13:58 -0400 (EDT)
Subject: [gtkmm bugzilla] [Bug 339791] Gtk::Menu crash with child

Do not reply to this via email (we are currently unable to handle email
responses and they get discarded).  You can add comments to this bug at
http://bugzilla.gnome.org/show_bug.cgi?id=3D339791
 gtkmm | general | Ver: 2.8.x





------- Comment #16 from Paul Davis  2006-05-17 13:13 UTC -------
Another aha!

gtkmm/gtk/gtkmm/menu_elems.cc:93-96
MenuElem::MenuElem(const Glib::ustring& label, Menu& submenu)
{
  set_child( manage(new MenuItem(label, true)) );
  child_->set_submenu(submenu);
  child_->show();
}

We're talking about containers, but we're not in a container.  Or rather,=
 this
is not a container interface we're dealing with.

In Gtk::MenuItem, the submenu is stored as a member variable.  Its not st=
ored
with a container interface where we can just remove() it, we have to call
remove_submenu() to get rid of the reference before we destroy it.

The Widget_Class::dispose_vfunc_callback would remove the Gtk::Label if i=
t
happened to be unmanaged, but not touch the submenu.

Now the question is, why does our managed menu get destroyed properly?

And I cannot answer this.  All I can say is that the MenuItem destructor =
never
seems to get run.  Which I find odd.  But from my g_warning outputs it do=
esn't
appear to be running.


--=20
Configure bugmail: http://bugzilla.gnome.org/userprefs.cgi?tab=3Demail
------- You are receiving this mail because: -------
You are the QA contact for the bug.
You are the assignee for the bug.


--__--__--

Message: 2
To: gtkmm-forge lists sourceforge net
From: "gtkmm (bugzilla.gnome.org)" <bugzilla-daemon bugzilla gnome org>
Date: Wed, 17 May 2006 09:26:29 -0400 (EDT)
Subject: [gtkmm bugzilla] [Bug 339791] Gtk::Menu crash with child

Do not reply to this via email (we are currently unable to handle email
responses and they get discarded).  You can add comments to this bug at
http://bugzilla.gnome.org/show_bug.cgi?id=3D339791
 gtkmm | general | Ver: 2.8.x





------- Comment #17 from Murray Cumming  2006-05-17 13:26 UTC -------
You've certainly given me some stuff to investigate. If you are right abo=
ut the
problem, it looks like we can find a solution.


--=20
Configure bugmail: http://bugzilla.gnome.org/userprefs.cgi?tab=3Demail
------- You are receiving this mail because: -------
You are the QA contact for the bug.
You are the assignee for the bug.


--__--__--

Message: 3
To: gtkmm-forge lists sourceforge net
From: "gtkmm (bugzilla.gnome.org)" <bugzilla-daemon bugzilla gnome org>
Date: Wed, 17 May 2006 10:31:24 -0400 (EDT)
Subject: [gtkmm bugzilla] [Bug 339791] Gtk::Menu crash with child

Do not reply to this via email (we are currently unable to handle email
responses and they get discarded).  You can add comments to this bug at
http://bugzilla.gnome.org/show_bug.cgi?id=3D339791
 gtkmm | general | Ver: 2.8.x





------- Comment #18 from Paul Davis  2006-05-17 14:31 UTC -------
Oh, and the hiererarchy as best as I can tell for the unamanged widget:

Gtk::Window
  -> Gtk::MenuBar
    -> Gtk::Menu ( m_parent )
      -> Gtk::MenuElem
        -> Gtk::MenuItem ( member of MenuElem )

          //This is a member variable, not a container relationship.
          //I'm pretty sure there's quite a difference, but I might be wr=
ong.
          -> Gtk::Menu ( m_child1 )

Well, crap. Looking at this makes me think I'm wrong again.  Damn it.
(This is a run of my test case.  Kind of. I dunno, but its got a g_warnin=
g in
Widget_Class::dispose_vfunc_callback().  I copied one of the DEBUG_REFCOU=
NT
warning message things to right below if( obj->referenced_ ) to see what
pointer was being removed from what container.  And the pointer for the F=
irst
Child is definitely being removed from something.

Athough, notice it then gets removed twice from nothing.  Well I suppose =
those
could be all the weird call back signals or what not.

First Child: 0x80b4050
Second Child: 0x80b4150
Parent: 0x80b4250

BEFORE DELETE PARENT
destructor for menu: parent
(test:9256): gtkmm-WARNING **: REMOVING AN UNMANAGED WIDGET gtkmm__GtkMen=
u


This line says we are in fact removing the Menu from some goddamn contain=
er.

(test:9256): gtkmm-WARNING **: Widget_Class::dispose_vfunc_callback(): re=
moving
gobject_: 0x80b4050 from parent: 0x80b6800


(test:9256): gtkmm-WARNING **: REMOVING AN UNMANAGED WIDGET gtkmm__GtkMen=
u
(test:9256): gtkmm-WARNING **: Widget_Class::dispose_vfunc_callback(): re=
moving
gobject_: 0x80b4050 from parent: (nil)
(test:9256): gtkmm-WARNING **: Destroying object: 0x80b8468
(test:9256): gtkmm-WARNING **: Refcount: 1
(test:9256): gtkmm-WARNING **: Would've destroyed submenu: 0x80b4050
(test:9256): gtkmm-WARNING **: REMOVING AN UNMANAGED WIDGET gtkmm__GtkMen=
u
(test:9256): gtkmm-WARNING **: Widget_Class::dispose_vfunc_callback(): re=
moving
gobject_: 0x80b4050 from parent: (nil)
destructor for menu: Second child
(test:9256): gtkmm-WARNING **: Destroying object: 0x80b84c8
AFTER DELETE PARENT

...

So I did some more poking, and I'm finding that when m_child1 is removed =
from
the container, it never detaches itself.

I think I might have another line of inquiry. I wonder if when a Menu is
removed from a container, it should be detached.

So, judging by some quick reading of the code, this could be done by list=
ening
to on_parent_change and if the new parent is NULL, detach.

Tried this quick by overriding on_parent_changed in Gtk::Menu.  Didn't wo=
rk.=20
Doesn't look like it got called. :(

There is something to this though I do believe.  gtk_menu_detach is faili=
ng
because its being called after the MenuItem is destroyed

Judging from this:
(test:27650): Gtk-CRITICAL **: gtk_menu_item_detacher: assertion
`GTK_IS_MENU_ITEM (widget)' failed

Which was part of the original output of the error program ( before my at=
tempt
at a patch )

So, the issue here is that when Gtk::Menu is removed from its container, =
it
should figure out to detach itself somehow.  I could check this real quic=
k to
see if it happens for any container or not.

If this happens for any container, my patch is dead.  And if it happens f=
rom
any container, Gtk::Menu is going to have to detect when its been removed=
,
which as far as I can tell is by on_parent_changed, cause thats all I see=
 being
called in the Bin::remove( Widget& w ) and Box::remove( Widget& w ) (just=
 two
random ones with different implementations for sampling).

But my mind is absolutely fried, so this is it for tonight, today, whatev=
er it
is now.

Hope that helps.


--=20
Configure bugmail: http://bugzilla.gnome.org/userprefs.cgi?tab=3Demail
------- You are receiving this mail because: -------
You are the QA contact for the bug.
You are the assignee for the bug.


--__--__--

Message: 4
To: gtkmm-forge lists sourceforge net
From: "gtkmm (bugzilla.gnome.org)" <bugzilla-daemon bugzilla gnome org>
Date: Wed, 17 May 2006 18:57:12 -0400 (EDT)
Subject: [gtkmm bugzilla] [Bug 341895] gtkmm 2.8.6/2.8.7 are utterly hosed

Do not reply to this via email (we are currently unable to handle email
responses and they get discarded).  You can add comments to this bug at
http://bugzilla.gnome.org/show_bug.cgi?id=3D341895
 gtkmm | general | Ver: 2.8.x





------- Comment #9 from Philip Langdale  2006-05-17 22:57 UTC -------
The two identified problems do indeed appear to be fixed. However, they h=
ave
uncovered an even nastier problem.

In a nutshell, what I see is that when I attempt to call a method that is
really a gobject virtual method on a non-gtkmmproc derived subclass, ever=
ything
goes to hell in a handbaskest and the vtable lookup to find the c++ virtu=
al
method goes wrong and calls a different method from what it should - as i=
n it
calls the next method in the table!

This is happening with libview specifically and only when dynamically lin=
ked.
If I statically link the subclass into my test case, it works correctly. =
It
makes no difference if I recompile libview against the latest glibmm/gtkm=
m or
if I use my previous binary.

This did not happen with 2.10.1/2.8.5.

Valgrind doesn't not report any invalid accesses before everything blows =
up
when the wrong method is called.

I will continue trying to narrow this down but it's very very evil.


--=20
Configure bugmail: http://bugzilla.gnome.org/userprefs.cgi?tab=3Demail
------- You are receiving this mail because: -------
You are the QA contact for the bug.
You are the assignee for the bug.


--__--__--

Message: 5
To: gtkmm-forge lists sourceforge net
From: "gtkmm (bugzilla.gnome.org)" <bugzilla-daemon bugzilla gnome org>
Date: Wed, 17 May 2006 19:20:53 -0400 (EDT)
Subject: [gtkmm bugzilla] [Bug 341895] gtkmm 2.8.6/2.8.7 are utterly hosed

Do not reply to this via email (we are currently unable to handle email
responses and they get discarded).  You can add comments to this bug at
http://bugzilla.gnome.org/show_bug.cgi?id=3D341895
 gtkmm | general | Ver: 2.8.x





------- Comment #10 from Philip Langdale  2006-05-17 23:20 UTC -------
I rebuilt gtkmm 2.8.5 against glibmm cvs and my testcase doesn't crash, s=
o the
cause is a gtkmm change. I guess that's good news.


--=20
Configure bugmail: http://bugzilla.gnome.org/userprefs.cgi?tab=3Demail
------- You are receiving this mail because: -------
You are the QA contact for the bug.
You are the assignee for the bug.


--__--__--

Message: 6
To: gtkmm-forge lists sourceforge net
From: "gtkmm (bugzilla.gnome.org)" <bugzilla-daemon bugzilla gnome org>
Date: Wed, 17 May 2006 19:39:26 -0400 (EDT)
Subject: [gtkmm bugzilla] [Bug 341895] gtkmm 2.8.6/2.8.7 are utterly hosed

Do not reply to this via email (we are currently unable to handle email
responses and they get discarded).  You can add comments to this bug at
http://bugzilla.gnome.org/show_bug.cgi?id=3D341895
 gtkmm | general | Ver: 2.8.x





------- Comment #11 from Philip Langdale  2006-05-17 23:39 UTC -------
Ok, it's the obvious guilty change. The change in editable.hg that replac=
ed the=20

_VFUNC_H(insert_text_vfunc, void, `const Glib::ustring& text, int& positi=
on')

with

virtual void insert_text_vfunc(const Glib::ustring& text, int& position);

is the cause of the problem. Reverting that fixed the crash. In my specif=
ic
case, the attempt to call delete_text_vfunc was going off the deep end an=
d
calling get_chars_vfunc instead. We can see why this would happen from lo=
oking
at the generated editable.h. insert_text_vfunc has been reordered below a=
ll the
other vfuncs. So, an existing binary would still call at the delete_text_=
vfunc
offset, but now get get_chars_vfunc - as we observe.

I can't explain why my rebuilt libview still crashed though - maybe I did=
n't
really rebuild it or something else silly went wrong.

Anyway, the correct fix is either to revert the change or to redo it in s=
uch a
way that the method declaration order does not change.


--=20
Configure bugmail: http://bugzilla.gnome.org/userprefs.cgi?tab=3Demail
------- You are receiving this mail because: -------
You are the QA contact for the bug.
You are the assignee for the bug.


--__--__--

Message: 7
To: gtkmm-forge lists sourceforge net
From: "gtkmm (bugzilla.gnome.org)" <bugzilla-daemon bugzilla gnome org>
Date: Wed, 17 May 2006 19:43:04 -0400 (EDT)
Subject: [gtkmm bugzilla] [Bug 341895] gtkmm 2.8.6/2.8.7 are utterly hosed

Do not reply to this via email (we are currently unable to handle email
responses and they get discarded).  You can add comments to this bug at
http://bugzilla.gnome.org/show_bug.cgi?id=3D341895
 gtkmm | general | Ver: 2.8.x





------- Comment #12 from Philip Langdale  2006-05-17 23:43 UTC -------
Other headers that were tweaked so that method reordering might have occu=
red:

pixbuf.hg
pixbufloader.hg
celllayout.hg
treeviewcolumn.hg


--=20
Configure bugmail: http://bugzilla.gnome.org/userprefs.cgi?tab=3Demail
------- You are receiving this mail because: -------
You are the QA contact for the bug.
You are the assignee for the bug.


--__--__--

Message: 8
To: gtkmm-forge lists sourceforge net
From: "gtkmm (bugzilla.gnome.org)" <bugzilla-daemon bugzilla gnome org>
Date: Wed, 17 May 2006 21:00:41 -0400 (EDT)
Subject: [gtkmm bugzilla] [Bug 341895] gtkmm 2.8.6/2.8.7 are utterly hosed

Do not reply to this via email (we are currently unable to handle email
responses and they get discarded).  You can add comments to this bug at
http://bugzilla.gnome.org/show_bug.cgi?id=3D341895
 gtkmm | general | Ver: 2.8.x





------- Comment #13 from Philip Langdale  2006-05-18 01:00 UTC -------
Further investigation reveals:

pixbuf.hg:

Not reodered. Function bodies look correct.

celllayout.hg
treeviewcolumn.hg

New add_attribute method shifts method offsets.

pixbufloader.hg:

The new header is not reordered but write() and close() have useless func=
tion
bodies. The exception management boilerplate is present but not the funct=
ion
call itself.

There may be additional uses of whatever generation template produced the=
se
bodies, but it's hard to see.

More seriously, I cannot guarantee that there are not additional classes =
of
generated method that are not flawed but which have yet to be observed. I=
t's a
large diff to trawl through.

But for now, with these known problems fixed, I am not observing any othe=
r
negative symptoms.


--=20
Configure bugmail: http://bugzilla.gnome.org/userprefs.cgi?tab=3Demail
------- You are receiving this mail because: -------
You are the QA contact for the bug.
You are the assignee for the bug.



--__--__--

_______________________________________________
Gtkmm-forge mailing list
Gtkmm-forge lists sourceforge net
https://lists.sourceforge.net/lists/listinfo/gtkmm-forge


End of Gtkmm-forge Digest
[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]