Closed Bug 241535 Opened 20 years ago Closed 7 years ago

Assertion failure on destroying XEmbed plug-in

Categories

(Core Graveyard :: Plug-ins, defect)

Other Branch
x86
Linux
defect
Not set
normal

Tracking

(Not tracked)

RESOLVED INCOMPLETE

People

(Reporter: braden, Assigned: chpe)

References

Details

(Keywords: assertion)

Attachments

(1 file, 1 obsolete file)

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).
Attached file A test XEmbed plug-in
This attachment demonstrates the GLib assertion failure.
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.
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.
What's the assertion, exactly?
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
[...]
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?
(In reply to comment #6)
> Is totem using an in-process GtkPlug?

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

Attached patch proposed patch (obsolete) — Splinter Review
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?).
Is someone able to review the proposed patch?
Comment on attachment 241087 [details] [diff] [review]
proposed patch

doubtful, we lack gtk experts
Attachment #241087 - Flags: review?(caillon)
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.
Attachment #241087 - Flags: review?(caillon) → review+
Is this assertion still firing on trunk?
Assignee: blizzard → nobody
QA Contact: plugins
Assignee: nobody → chpe
Keywords: assertion
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)...
Attachment #241087 - Attachment is obsolete: true
Status: NEW → RESOLVED
Closed: 7 years ago
Resolution: --- → INCOMPLETE
Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: