241535 - Assertion failure on destroying XEmbed plug-in

Status: RESOLVED INCOMPLETE

(Core Graveyard :: Plug-ins, defect)

Description

[Braden]

A GLib assertion failure is triggered when calling gtk_widget_destroy on the
GtkPlug created for an XEmbed plug-in (in, for instance, NPP_Destroy).

Comment 1

[Braden]

Attachment: A test XEmbed plug-in

This attachment demonstrates the GLib assertion failure.

Comment 2

[Braden]

I suspect this assertion failure indicates a situation that can give rise to
memory corruption or somesuch insidiousness. The plug-in I'm actually trying to
write is crashing; and I strongly suspect that crash is linked to this assertion
failure.

Comment 3

[Braden]

Strike comment #2. There was a shutdown problem in my GTK widget that just
hadn't surfaced in other contexts.

I'll leave this bug open for now. The GLib assertion failure is real; and if it
is in fact benign, then something should probably be done to quell it.

Comment 4

[Christopher Blizzard (:blizzard)]

What's the assertion, exactly?

Comment 5

[Christian Persch (GNOME) (away; not receiving bug mail)]

I think I'm seeing the same problem with the totem plugin: the plugin embedded viewer crashes, and when closing the browser (shutdown), I get this:

(epiphany:24898): Gtk-CRITICAL **: gtk_widget_destroy: assertion `GTK_IS_WIDGET (widget)' failed

Trace:
#3  0xb6ed0c1a in g_return_if_fail_warning (log_domain=0xbf8697bb "trap", pretty_function=0xb7b43a17 "gtk_widget_destroy", expression=0xbf8697bb "trap")
    at gmessages.c:532
#4  0xb7a5e3a7 in gtk_widget_destroy (widget=0x8625e98) at gtkwidget.c:2156
#5  0xb64b7ae0 in ~nsPluginNativeWindowGtk2 (this=0x8800778) at nsPluginNativeWindowGtk2.cpp:91
#6  0xb64b7b2c in PLUG_DeletePluginNativeWindow (aPluginNativeWindow=0xb7ee3358) at nsPluginNativeWindowGtk2.cpp:107
#7  0xb64a2287 in nsPluginHostImpl::DeletePluginNativeWindow (this=0x8779818, aPluginNativeWindow=0xbf8697bb) at nsPluginHostImpl.cpp:6529
#8  0xb602e5e8 in ~nsPluginInstanceOwner (this=0x87091d8) at nsObjectFrame.cpp:2363
#9  0xb602cc33 in nsPluginInstanceOwner::Release (this=0xb7ee3358) at nsObjectFrame.cpp:2373
#10 0xb64b27a6 in ~nsPluginInstancePeerImpl (this=0x87fa110) at nsPluginInstancePeer.cpp:78
#11 0xb64b3539 in nsPluginInstancePeerImpl::Release (this=0xb7ee3358) at nsPluginInstancePeer.cpp:91
#12 0xb64a5144 in ~nsActivePlugin (this=0x8895180) at nsPluginHostImpl.cpp:413
#13 0xb64a51fd in nsActivePluginList::remove (this=0x8779848, plugin=0x8895180) at nsPluginHostImpl.cpp:532
#14 0xb64a53db in nsActivePluginList::shut (this=0x8779848) at nsPluginHostImpl.cpp:457
#15 0xb64ac2bf in nsPluginHostImpl::Destroy (this=0x8779818) at nsPluginHostImpl.cpp:3214
#16 0xb64a3ebf in nsPluginHostImpl::Observe (this=0x8779818, aSubject=0x81b51dc, aTopic=0xbf8697bb "trap", someData=0x0) at nsPluginHostImpl.cpp:6141
#17 0xb6e270c3 in nsObserverService::NotifyObservers (this=0x82742b0, aSubject=0x81b51dc, aTopic=0xb6e80935 "xpcom-shutdown", someData=0x0)
    at nsObserverService.cpp:233
#18 0xb6e1f196 in NS_ShutdownXPCOM_P (servMgr=0x0) at nsXPComInit.cpp:797
#19 0xb7f3d77d in NS_ShutdownXPCOM (svcMgr=0xbf8697bb) at nsXPComStub.cpp:140
#20 0xb7f4d068 in NS_TermEmbedding () at nsEmbedAPI.cpp:215
[...]

Comment 6

[Braden]

I wasn't able to respond to Chris' query because this problem stopped showing up for me. I wish I could say exactly what did it; but I was making frequent dramatic changes to my plug-in at the time and I really can't say with any certainty what made this assertion go away.

I do have a suspicion, though. If you look at the test case I attached (which I haven't compiled and run for two years, BTW), a significant thing about it is that it creates the GtkPlug in-process. Some time ago I switched to an out-of-process GtkPlug in my plug-in; and a lot of things just started working better.

Is totem using an in-process GtkPlug?

Comment 7

[Christian Persch (GNOME) (away; not receiving bug mail)]

(In reply to comment #6)
> Is totem using an in-process GtkPlug?

No, the totem plugin starts a separate process that handles the content.

Comment 8

[Christian Persch (GNOME) (away; not receiving bug mail)]

Attachment: proposed patch

It doesn't seem to make any difference whether the plugin actually displays anything in the socket; a test plugin which just does nothing triggers the same warning for me.
The problem seems to be that mGtkSocket is destroyed when the tab is closed (or the page unloaded?), but the nsPluginNativeWindowGtk2 seems to live longer than that (a leak? or expected?).

Comment 9

[Reinout van Schouwen]

Is someone able to review the proposed patch?

Comment 10

[timeless]

Comment on attachment 241087 [details] [diff] [review]
proposed patch

doubtful, we lack gtk experts

Comment 11

[Christopher Aillon (sabbatical, not receiving bugmail)]

Comment on attachment 241087 [details] [diff] [review]
proposed patch

r=caillon, but there should be a bug on file to find out why nsPluginNativeWindowGtk2 is not getting destroyed properly.  This patch should be reverted when that is fixed.  A FIXME comment would be great, as well.

Comment 12

[Karl Tomlinson (:karlt back Feb 10)]

Is this assertion still firing on trunk?

Comment 13

[Christian Persch (GNOME) (away; not receiving bug mail)]

Comment on attachment 241087 [details] [diff] [review]
proposed patch

Bug 397992 fixed the crash/critical warning in a different but equivalent way, so I think this doesn't crash anymore. Still, it would be good to figure out why this object is only destroyed on shutdown (comment 11)...