Re: [BUG] Calling clutter_actor_destroy from JS makes the Shell SIGABRT

On Sun, 2010-10-31 at 19:36 +0100, Giovanni Campagna wrote:
> This is a bug that can be experienced for example with the patch from
> bug 618312 (the bluetooth indicator). To reproduce, enable then disable
> bluetooth. Device items are removed from menu by calling .destroy on
> PopupBaseMenuItem.
> What is my experimental understanding is that calling .destroy on a
> StBin corrupts the proxy of that (or another? can't really say, JS stack
> when breaking on st_bin_dispose points to a wrong line) StBin and
> results in a failed assertion (unreffing a finalized object).

We certainly call destroy() on ClutterActors in other places so there
has to be more to it than simply that.

> I didn't post this in bugzilla because I am not sure where this bug
> belongs:
> - is this a gjs bug? Maybe g_object_run_dispose confuses the GC because
> the object is dropping references to JS objects, as well as GObject.
> Also, this is often preceded by some failed assertions in
> g_object_add_toggle_ref / g_object_remove_toggle_ref
> - is this a St bug? The proxy object is a [_private_St_Bin], so it
> reasonable to assume that the GObject was an ST_TYPE_BIN (but I'm not
> sure on this either, sometimes shell crashes with gjs trying to handle
> an StBin with an StLabel prototype).
> - is this a clutter bug? The method invoked is clutter_actor_destroy,
> after all.

I'm going to guess this is a reference counting bug somewhere in St -
perhaps we're emitting a signal and creating a JS proxy for an object
after GObject has already decided to finalize it or something like that.

It's also possible that there is some corner case that GJS isn't
handling properly.

> I'm sending this because I have no clue of the possible cause of this,
> but it is really annoing to have the shell randomly crash (especially
> because it corrupts ORBIT somehow, so the panel loads with no applets).

Random crashes are indeed bad! :-)

What would be really cool is if you can figure out how to create a JS
test in the style of gnome-shell/tests/interactive that reproduces the
bug. This kind of stuff isn't easy to track down and the smaller and
simpler the test case, the more luck we'll have tracking throw the code
in the internals of GObject and GJS.

- Owen

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