|
List Info
Thread: Glib 1.102 (stable)
|
|
| Glib 1.102 (stable) |

|
2006-01-13 23:21:55 |
On Thu, Dec 15, 2005 at 10:44:42AM -0500, Sean Dague wrote:
<snip>
> > This looks like you have a perl-derived
CellRenderer in your code.
> > In frame #5,
gtk_tree_view_column_cell_set_cell_data() is calling
> > g_object_set_property() on something, most likely
using an attribute
> > set up when the TreeViewColumn was created.
> >
> > The first red flag is the value of property_name
in frame #4 -- is
> > that a garbage string or a unicode string? I
believe that most of
> > the code assumes property names will be ASCII.
This questionable
> > value appears to have been mapped to a decent
property id for the
> > call to gperl_type_set_property(), which is in the
vtable for perl-
> > derived GObjects. When gperl_type_set_property()
discovers there is
> > no SET_PROPERTY() in the package and no sub
registered as a set
> > handler, it falls back to setting a key in the
wrapper hash with the
> > same name as the property. However, as you see in
the trace, the
> > name in frame #2 does not match the property_name
in frame #4.
The following program was provided by one of our users that
demonstrates the
glib crash we're seeing. Hopefully this will help figure
out if there is a
bug in glib, or a bug in our brains, and we should be doing
something
different.
#!/usr/bin/perl -w
# With Glib Perl v1.101 this script does not crash, but with
v1.102
# it does. Removing the lines with BUG fixes the problem.
Sadly
# fixing it tends to be more difficult in practice.
#
# On 1.102 I get:
#
# bash$ perl crash.pl
# INIT_INSTANCE
# Segmentation fault (core dumped)
# bash$ fgrep -v BUG crash.pl >work.pl
# bash$ perl work.pl
# INIT_INSTANCE
# Success made it to GET_SIZE
#
package CrashTest::CellRenderer;
use strict;
use Glib qw(G_PARAM_READWRITE);
use Gtk2;
use Glib::Object::Subclass "Gtk2::CellRenderer",
properties => [ Glib::ParamSpec->string('text',
'Text',
'The text string to display', '',
G_PARAM_READWRITE) ];
sub INIT_INSTANCE { warn "INIT_INSTANCEn"; }
sub GET_SIZE { die "Made it to GET_SIZEn"; }
sub RENDER { die "Made it to RENDERn"; }
package main;
use strict;
use Glib;
use Gtk2 -init;
my $window = Gtk2::Window->new;
my $view;
{ # BUG: remove these brackets and it works!
my $treestore = Gtk2::TreeStore->new(qw/Glib::String/);
my $iter = $treestore->append(undef);
$treestore->set($iter, 0, "Row 1",);
$view = Gtk2::TreeView->new($treestore);
my $renderer = CrashTest::CellRenderer->new;
my $col =
Gtk2::TreeViewColumn->new_with_attributes("Simple
text",
$renderer,
"text" => 0);
$view->append_column($col);
} # BUG: remove these brackets and it works!
$window->add ($view);
$window->show_all;
Gtk2->main;
--
____________________________________________________________
______
Sean Dague Mid-Hudson
Valley
sean at dague dot net Linux Users
Group
http://dague.net
http://mhvlug.org
There is no silver bullet. Plus, werewolves make better
neighbors
than zombies, and they tend to keep the vampire population
down.
____________________________________________________________
______
_______________________________________________
gtk-perl-list mailing list
gtk-perl-list gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-perl-list
|
|
| Glib 1.102 (stable) |

|
2006-01-14 03:04:28 |
On Jan 13, 2006, at 6:21 PM, Sean Dague wrote:
> The following program was provided by one of our users
that
> demonstrates the
> glib crash we're seeing. Hopefully this will help
figure out if
> there is a
> bug in glib, or a bug in our brains, and we should be
doing something
> different.
Many thanks, i wouldn't have found this without your code.
Wow, how embarrassing. This is an overlooked problem with
the undead
objects patch from last fall.
The tipoff was that i could keep the crash from happening by
providing a SET_PROPERTY() in your class. This avoids all
of the
fallback-to-hash-key machinery.
1. The cell renderer is created and added to the column in
the view.
2. The surrounding block goes out of scope, and the cell
renderer's
wrapper hash is marked "undead".
3. From $window->show_all, the treeview starts to paint
itself, and
needs to render columns.
4. TreeViewColumn calls g_object_set_property() on the
CrashTest::CellRenderer.
5. We wind up in gperl_type_set_property(), as this is a
perl-derived
class.
6. gperl_type_set_property() sees that
CrashTest::CellRenderer::SET_PROPERTY does not exist, so it
goes into
the code that will use the key in the wrapper hash.
7. It calls _gperl_fetch_wrapper_key() to get the wrapper
key from
the object.
8. _gperl_fetch_wrapper_key() calls g_object_get_qdata() to
fetch the
wrapper HV.
9. _gperl_fetch_wrapper_key() passes the wrapper HV to
hv_fetch().
10. BOOM!
It goes boom because in step 2, the wrapper hash was marked
undead.
This happens by using an evil C trick, which is manipulating
the low
bits in the pointer value, which are unused due to word
alignment.
However, _gperl_fetch_wrapper_key() doesn't account for the
fact that
the pointer may have been adjusted to mark the wrapper as
undead, and
in this case, that's exactly what happened. We wind up
passing an
invalid pointer to hv_fetch(), and the world comes crashing
down
around us.
Note that this didn't happen when you removed the braces
because you
didn't allow $renderer to go out of scope and become undead!
The fix is a one-liner, applied to both stable-1-10 and
HEAD.
Index: GObject.xs
============================================================
=======
RCS file: /cvsroot/gtk2-perl/gtk2-perl-xs/Glib/GObject.xs,v
retrieving revision 1.48.2.2
diff -u -r1.48.2.2 GObject.xs
--- GObject.xs 13 Nov 2005 18:07:10 -0000 1.48.2.2
+++ GObject.xs 14 Jan 2006 02:43:35 -0000
 -768,6
+768,11 
SV * svname;
HV * wrapper_hash;
wrapper_hash = g_object_get_qdata (object, wrapper_quark);
+
+ /* we don't care whether the wrapper is alive or undead.
forcibly
+ * remove the undead bit, or the pointer will be unusable.
*/
+ wrapper_hash = REVIVE_UNDEAD (wrapper_hash);
+
svname = newSVpv (name, strlen (name));
svp = hv_fetch (wrapper_hash, SvPV_nolen (svname), SvLEN
(svname)-1,
FALSE); /* never create on the first try;
prefer
I do apologize, as i should've caught that in patch review.
--
"Ghostbusters" is the best movie of this decade.
-- Neal, circa 1996, referring to a movie released in
1984.
_______________________________________________
gtk-perl-list mailing list
gtk-perl-list gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-perl-list
|
|
| Glib 1.102 (stable) |

|
2006-01-14 20:58:55 |
On Fri, Jan 13, 2006 at 10:04:28PM -0500, muppet wrote:
>
> On Jan 13, 2006, at 6:21 PM, Sean Dague wrote:
>
> >The following program was provided by one of our
users that
> >demonstrates the
> >glib crash we're seeing. Hopefully this will help
figure out if
> >there is a
> >bug in glib, or a bug in our brains, and we should
be doing something
> >different.
>
> Many thanks, i wouldn't have found this without your
code.
Excellent, glad we could help.
Any chance of getting a Glib 1.103 out there soon with this?
A lot of our
users are on Fedora, and all started to get the 1.102 update
a couple weeks
ago, which is causing all kinds of pain, and explainations
on how to prevent
package updates. I assume Fedora will update to the new
package relatively
quickly once there is a new release.
-Sean
--
____________________________________________________________
______
Sean Dague Mid-Hudson
Valley
sean at dague dot net Linux Users
Group
http://dague.net
http://mhvlug.org
There is no silver bullet. Plus, werewolves make better
neighbors
than zombies, and they tend to keep the vampire population
down.
____________________________________________________________
______
_______________________________________________
gtk-perl-list mailing list
gtk-perl-list gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-perl-list
|
|
| Glib 1.102 (stable) |

|
2006-01-14 21:16:50 |
On Sat, 2006-01-14 at 15:58 -0500, Sean Dague wrote:
> Any chance of getting a Glib 1.103 out there soon with
this? A lot of our
> users are on Fedora, and all started to get the 1.102
update a couple weeks
> ago, which is causing all kinds of pain, and
explainations on how to prevent
> package updates. I assume Fedora will update to the
new package relatively
> quickly once there is a new release.
There'll be a new unstable release on Monday, so I guess
that would be a
good time to release a new stable version as well.
--
Bye,
-Torsten
_______________________________________________
gtk-perl-list mailing list
gtk-perl-list gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-perl-list
|
|
| Glib 1.102 (stable) |

|
2006-01-16 17:11:42 |
Torsten Schoenfeld <kaffeetisch gmx.de> writes:
> > Any chance of getting a Glib 1.103 out there soon
with this? A
> > lot of our users are on Fedora, and all started to
get the 1.102
> > update a couple weeks ago, which is causing all
kinds of pain, and
> > explainations on how to prevent package updates.
I assume Fedora
> > will update to the new package relatively quickly
once there is a
> > new release.
>
> There'll be a new unstable release on Monday, so I
guess that would
> be a good time to release a new stable version as well.
does this bug also affect 1.08x?
_______________________________________________
gtk-perl-list mailing list
gtk-perl-list gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-perl-list
|
|
| Glib 1.102 (stable) |

|
2006-01-16 19:06:03 |
On Mon, 2006-01-16 at 18:11 +0100, Thierry Vignaud wrote:
> > There'll be a new unstable release on Monday, so I
guess that would
> > be a good time to release a new stable version as
well.
>
> does this bug also affect 1.08x?
No, 1.08x didn't have the UNDEAD stuff yet.
--
Bye,
-Torsten
_______________________________________________
gtk-perl-list mailing list
gtk-perl-list gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-perl-list
|
|
| Glib 1.102 (stable) |

|
2006-01-16 20:02:39 |
Thierry Vignaud said:
> does this bug also affect 1.08x?
No. The last change on stable-1-08 was in June, and the
changes which caused
Sean's bug were made in October on HEAD and stable-1-10.
However, 1.08x *will* break when gtk+ is upgraded to a
version including
GInitiallyUnowned.
--
muppet <scott at asofyet dot org>
_______________________________________________
gtk-perl-list mailing list
gtk-perl-list gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-perl-list
|
|
[1-7]
|
|