550983 - X_ChangeProperty: BadWindow fatal error in plugin process

Status: RESOLVED INCOMPLETE

(Core Graveyard :: Plug-ins, defect)

Description

[Karl Tomlinson (:karlt)]

I'm still seeing a couple of reports similar to bug 540114 suggesting that it is not 100% fixed.

bp-38a4fdac-68f4-462d-ad90-fa5802100304
bug 517133 comment 7

Comment 1

[Karl Tomlinson (:karlt)]

My first hypothesis was that perhaps the plugin's X server requests might still be waiting to be processed at the time the browser was checking for child windows in socket_unrealize_cb.  However, gtk_plug_realize is called (synchronously) during gtk_widget_show called from libflashplayer, and for out-of-process GtkPlugs (GTK_WIDGET_TOPLEVEL (widget)) gtk_plug_realize syncs the display after creating the plug window with the socket parent.

Comment 2

[Karl Tomlinson (:karlt)]

Another hypothesis to consider is that the foreign GdkWindows in the browser process might be leaking, or perhaps even rapid XID reuse, may be causing the gdk_window_lookup(child) here to return a false positive:
http://hg.mozilla.org/mozilla-central/annotate/d70ef56fdca6/modules/plugin/base/src/nsPluginNativeWindowGtk2.cpp#l473

Comment 3

[Daniel C]

I didn't manage to reproduce the crash when I tried, only causing messages like the following to appear when closing a YouTube tab:

(<unknown>:5391): Gdk-CRITICAL **: gdk_window_get_origin: assertion `GDK_IS_WINDOW (window)' failed

(<unknown>:5391): Gdk-CRITICAL **: gdk_window_get_origin: assertion `GDK_IS_WINDOW (window)' failed
  (child won, so we're not deferring)
  (child won, so we're deferring)
  (processing deferred in-call)
  (child won, so we're not deferring)
  (child won, so we're deferring)
  (processing deferred in-call)

  ... (many times) ...

  (child won, so we're not deferring)
  (child won, so we're deferring)
  (processing deferred in-call)
  (child won, so we're not deferring)
  (child won, so we're deferring)
  (processing deferred in-call)
NOTE: child process received `Goodbye', closing down

Actually it did hang once and I used kill -s ABRT on your suggestion to get: bp-c096fc6d-f669-49ad-b25a-c41be2100305

Comment 4

[Karl Tomlinson (:karlt)]

(In reply to comment #3)
> Actually it did hang once and I used kill -s ABRT on your suggestion to get:
> bp-c096fc6d-f669-49ad-b25a-c41be2100305

Thanks.  Do you know whether dom.ipc.plugins.enabled was set at that time?

Comment 5

[Daniel C]

It mentions ipc in the stack but I actually think it was disabled that time, sorry for the confusion. On a side note, perhaps certain preferences should be added to crash reports.

Comment 6

[Benjamin Smedberg]

Resolving old bugs which are likely not relevant any more, since NPAPI plugins are deprecated.