GNOME Bugzilla – Bug 359362
_write called before _set_window
Last modified: 2006-10-05 10:16:31 UTC
Using the browser plugin (w/ gstreamer 0.10) in epiphany on firefox 2.0 backend (edgy), I got an X deadlock (could be NV driver specific), and using epiphany on xulrunner trunk I get loads of scary warnings. The difference could be due to changed plugin instantiation on xr trunk. Steps: 0) Go to apple.com/trailers 1) Click on the trailer for "a scanner darkly" (debug output attached)
Created attachment 73965 [details] log
Works fine here, with both GStreamer and xine-lib. The D-Bus errors look nasty: ** (epiphany:5142): CRITICAL **: dbus_g_proxy_add_signal: assertion `g_datalist_id_get_data (&priv->signal_signatures, q) == NULL' failed Would you have proper backtraces (ie with line numbers) for those critical messages?
Created attachment 74003 [details] [review] log with full stack traces So the deadlock occured again, and I think it's a problem with the nonfree nvidia driver. And this bug seems to be specific to gecko trunk. What's happening is that while forking one plugin viewer, we recurse into reflow and forking another plugin, 'thanks' to the evil loop in totem_plugin_fork.
** (epiphany:5027): CRITICAL **: dbus_g_proxy_add_signal: assertion `g_datalist_id_get_data (&priv->signal_signatures, q) == NULL' failed
+ Trace 74481
Actually it's forking the SAME plugin again!
nsPluginNativeWindowGtk2: NPPVpluginNeedsXEmbed=1 nsPluginNativeWindowGtk2: call SetWindow with xid=0x2a01682 nsPluginNativeWindowGtk2: NPPVpluginNeedsXEmbed=0 nsPluginNativeWindowGtk2: call SetWindow with xid=0x2a01682 Why is it calling SetWindow twice with the same xid? (and then another time after that) We only fork once if we get a SetWindow call, and it's if the ->window isn't set. Why is it launching the first one without a --xid? There's something fishy there. Are you sure something isn't trampling on the stack?
>nsPluginNativeWindowGtk2: NPPVpluginNeedsXEmbed=1 >nsPluginNativeWindowGtk2: call SetWindow with xid=0x2a01682 >nsPluginNativeWindowGtk2: NPPVpluginNeedsXEmbed=0 >nsPluginNativeWindowGtk2: call SetWindow with xid=0x2a01682 Those don't result in totem_plugin_set_window getting called; that's only called later. It's calling the viewer without --xid because when it's getting forked in Write there hasn't been a SetWindow call yet. The SetWindow call comes only later when reflowing. It's not trampling on the stack, as far as I can tell. Recursing into reflow and forking again while forking gets the dbus signal handler connected with the same handler/data, maybe dbus-glib doesn't like that?
Argh. It was nice in the olden days, we could rely (well, could we?) on the _write call happening after the _set_window for embed with visuals. Best bet is to write to a FIFO of our own, and wait for a _set_window call when we're not hidden. What do you think?
bug 350297 is about starting the player ASAP, which should fix this particular problem. So I'll close this as a dupe. *** This bug has been marked as a duplicate of 350297 ***