359870 - [@ gtk_style_realize] crash on style reset after closing tab with xembed plugins with NPPVpluginKeepLibraryInMemory

Status: RESOLVED WORKSFORME

Description

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

(Filing here since nsPluginNativeWindowGtk2 seems to be responsible; but it also might be a widget:gtk2 or gtk+ bug.)

Steps to reproduce (taken from https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=210151 ):
0) Install totem plugin, start firefox
1) Go to a site with movie links, for example http://digital-desert.com/mpg-videos/
2) Open a non-movie link in a new tab, close the new tab [not sure this step is necessary]
3) Open a movie link in a new tab; wait for it to load in the totem plugin; close the tab
4) Right-click the movie link, Save Target As

Result:
Shortly after the gtk native filepicker shows, the application crashes.

Analysis:
There seems to be a problem with xembed plugins: when you close the tab that showed the plugin, the nsPluginNativeWindowGtk2 that wraps the GtkSocket is not destroyed yet (it is destroyed sometime later; I haven't yet noticed a pattern; at the very least it's destroyed on shutdown.) (Bug 241535 is caused by the same problem.)

Now, when the native gtk filepicker opens, it causes a style reset (#12 in trace). This is recursively propagated down the widget hierarchy, until it comes to the GtkSocket of the plugin window. That socket's widget->window at this point has a NULL colourmap, causing gtk_style_realize to segfault (NULL dereference).

Trace:
#0  0xb7bfac24 in gtk_style_realize (style=0x8bc43d0, colormap=0x0) at gtkstyle.c:839
#1  0xb7bfe1f0 in IA__gtk_style_attach (style=0x8bc3e00, window=0x88b1320) at gtkstyle.c:752
#2  0xb7ca4fe2 in gtk_widget_set_style_internal (widget=0x8d39c78, style=0x8bc3e00, initial_emission=0) at gtkwidget.c:5138
#3  0xb7ca513a in reset_rc_styles_recurse (widget=0x8d39c78, data=0x0) at gtkwidget.c:5348
#4  0xb67e49a3 in moz_container_forall (container=0x8277528, include_internals=1, callback=0xb7ca50d0 <reset_rc_styles_recurse>, callback_data=0x0)
    at mozcontainer.c:401
#5  0xb7af65fb in IA__gtk_container_forall (container=0x8277528, callback=0xb7ca50d0 <reset_rc_styles_recurse>, callback_data=0x0) at gtkcontainer.c:1261
#6  0xb7ca5129 in reset_rc_styles_recurse (widget=0x8277528, data=0x0) at gtkwidget.c:5351
#7  0xb7ab749f in gtk_bin_forall (container=0x8140738, include_internals=1, callback=0, callback_data=0x0) at gtkbin.c:133
#8  0xb7af65fb in IA__gtk_container_forall (container=0x8140738, callback=0xb7ca50d0 <reset_rc_styles_recurse>, callback_data=0x0) at gtkcontainer.c:1261
#9  0xb7ca5129 in reset_rc_styles_recurse (widget=0x8140738, data=0x0) at gtkwidget.c:5351
#10 0xb7ca518d in IA__gtk_widget_reset_rc_styles (widget=0x8140738) at gtkwidget.c:5361
#11 0xb7bcde40 in gtk_rc_reset_widgets (settings=0x8065080) at gtkrc.c:1606
#12 0xb7b54bb1 in reset_styles_idle (user_data=0x8ddda48) at gtkicontheme.c:602
#13 0xb759caa1 in g_idle_dispatch (source=0x8cbbf90, callback=0, user_data=0x8ddda48) at gmain.c:3926
#14 0xb759e802 in IA__g_main_context_dispatch (context=0x8081bc0) at gmain.c:2045
#15 0xb75a17df in g_main_context_iterate (context=0x8081bc0, block=1, dispatch=1, self=0x8123360) at gmain.c:2677
#16 0xb75a1b89 in IA__g_main_loop_run (loop=0x8e61630) at gmain.c:2881
#17 0xb7b07dfb in IA__gtk_dialog_run (dialog=0x8e80000) at gtkdialog.c:996
#18 0xb67f91bd in nsFilePicker::Show (this=0x8dee8b8, aReturn=0xbfb9f5cc) at nsFilePicker.cpp:583
[...]

Downstream bug reports: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=210151 (firefox) and http://bugzilla.gnome.org/show_bug.cgi?id=353503 (epiphany, many duplicates).

Comment 1

[[:Aleksej]]

Debian testing
totem-mozilla 2.16.2-2

Crash when closing Firefox (with [X]):

Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.1) Gecko/20061010 Firefox/2.0
Talkback ID: TB25758224X.

Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9a1) Gecko/20061106 Minefield/3.0a1
Talkback ID: TB25757932W.

Comment 2

[Adam Guthrie]

Just curious, but have you tested to see if it crashes with a build with your patch from bug 241535 in it?

Comment 3

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

Those talkbacks match bug 241535, and are fixed by the patch there.
This bug isn't fixed by the patch there.

Comment 4

[Reinout van Schouwen]

This bug still causes many duplicate crash reports for both Epiphany and Galeon.

Comment 5

[timeless]

[e-mail]: that's nice. are you volunteering to work on it?

Comment 6

[Alexander Sack]

Aleksej, can you still reproduce this with both branch and trunk builds?

Comment 7

[[:Aleksej]]

totem-mozilla 2.16.5-2, latest Firefox (2007030104)
1.8: TB29817710W
Trunk: TB29817976K

Comment 8

[Alexander Sack]

I'll give it a try. stay tuned.

Comment 9

[Alexander Sack]

Created attachment 257133 [details] [diff] [review]
maybe this (1.8 branch)

As mentioned by reporter, destructor is not called when nsPluginNativeWindowGtk2 gets removed. In consequence window/widget does not get properly removed from gtk widget hierachy.

This patch removed widget properly from hierachy.

I did not change destructor code (which does basically the same, but is not called), but instead set mGtkSocket = 0 in this patch ... so should be safe.

Should be the same on trunk.

Someone can please verify that this fixes 1.8 + trunk build so i can ask for review?

Comment 10

[Alexander Sack]

Comment on attachment 257133 [details] [diff] [review]
maybe this (1.8 branch)

this patch breaks other plugins.

Comment 11

[Alexander Sack]

ok the bug is due to broken implementation of NPPVpluginKeepLibraryInMemory ... fix is not simple, so we worked around this by dropping that option from totem:

The workaround patch for totem is here:

http://bugzilla.gnome.org/show_bug.cgi?id=415389

However NPPVpluginKeepLibraryInMemory should be fixed or completely disabled at some point. So this bugs should be kept open.

Comment 12

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

Bug 371387 comment 19 and 20 indicate that this crash also happens for plugins which don't use NPPVpluginKeepLibraryInMemory.

Comment 13

[Alexander Sack]

(In reply to comment #12)
> Bug 371387 comment 19 and 20 indicate that this crash also happens for plugins
> which don't use NPPVpluginKeepLibraryInMemory.

Yes, it happens with latest totem too. It just needs a modified testcase:

(From: https://bugs.launchpad.net/ubuntu/+source/firefox/+bug/91334)

Steps to reproduce:
1. Visit
http://www.apple.com/getamac/ads/
2. Wait for "Hello I'm a Mac" then click on the "Tech Support" video at the bottom left. A video should start to play.
3. Repeat step 2 until video area no longer starts playing the video.
4. Start
gnome-theme-manager .
5. Change the theme from Human to Mist.

Comment 14

[Todd Whiteman]

This is also happening with Komodo and the Scintilla plugin, which does not use NPPVpluginKeepLibraryInMemory.

Way to reproduce this bug within Komodo:
1) After closing an opened file (plugin is removed) and then opening the native file open dialog.
2) After closing an opened file (plugin is removed) and then changing the theme.

The gdb stacktrace for Komodo is the same as posted in the main part of the bug above.

Reference: http://bugs.activestate.com/show_bug.cgi?id=64037

Comment 15

[Reed Loden [:reed] (use needinfo?)]

Is this still a problem on trunk with all the fixes that have landed in the plugins code?

Comment 16

[Todd Whiteman]

I *cannot* reproduce this exact problem using a "Komodo on Mozilla trunk" build, but I am getting some nasty looking GTK errors when shutting down the application:

(gecko:10908): Gdk-CRITICAL **: gdk_screen_get_display: assertion `GDK_IS_SCREEN (screen)' failed
(gecko:10908): GLib-GObject-WARNING **: invalid (NULL) pointer instance
(gecko:10908): GLib-GObject-CRITICAL **: g_signal_handlers_disconnect_matched: assertion `G_TYPE_CHECK_INSTANCE (instance)' failed
(gecko:10908): GLib-GObject-CRITICAL **: g_object_ref: assertion `G_IS_OBJECT (object)' failed
(gecko:10908): Gdk-CRITICAL **: gdk_screen_get_display: assertion `GDK_IS_SCREEN (screen)' failed
(gecko:10908): GLib-GObject-CRITICAL **: g_object_get_data: assertion `G_IS_OBJECT (object)' failed
(gecko:10908): Gdk-CRITICAL **: gdk_screen_get_display: assertion `GDK_IS_SCREEN (screen)' failed
(gecko:10908): GLib-GObject-CRITICAL **: g_object_get_data: assertion `G_IS_OBJECT (object)' failed

.... (same errors repeat numerous times)

Comment 17

[Alexander Sack]

verified that the testcase in https://bugs.launchpad.net/ubuntu/+source/firefox/+bug/91334 doesn't crash firefox beta 3.

Closing bug.

Comment 18

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

asac: Have you also verified that it doesn't crash anymore with the steps from comment 14 ?

Comment 19

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

BTW, I think http://bugzilla.gnome.org/show_bug.cgi?id=467698 sheds some light on what's really going on here that's caused/causing the crash.

Comment 20

[sam morris]

I've hit this a few times recently with xulrunner 1.9. Various beta versions and most recently with rc2.

Comment 21

[sam morris]

A trace can be found at http://bugzilla.gnome.org/show_bug.cgi?id=538522.

Comment 22

[sam morris]

A trace can be found at http://bugzilla.gnome.org/show_bug.cgi?id=538522. How can I re-open the bug?

Comment 23

[Reinout van Schouwen]

Reopening bug as requested.

Comment 24

[timeless]

reclosing. [e-mail]: don't reopen bugs without getting people to specify versions.

[e-mail]: don't complain about xulrunner 1.9 beta 5 when the current release of gecko is 1.9 <final>.

[e-mail]: this bug is a bug in gtk not a bug in gecko, and you haven't specified the version of gtk you were using. you have otoh managed to make a hash out of this bug system.

Comment 25

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

@timeless: 
- Comment 20 mentions that it also occurred on rc2, which is about code-identical to final.
- On what grounds do you claim that this is a gtk bug? In comment 19 I linked to a gnome bug report that indicates that gecko's use of gtk_widget_set_parent_window might be responsible for this problem.

Comment 26

[timeless]

sorry, i was looking at http://bugzilla.gnome.org/show_bug.cgi?id=467698#c48

if you have some evidence that a bug is still valid, you're welcome to reopen it. however i do not want qa to reopen bugs based on requests which point to old versions of products and do not specify versions of relevant libraries (the fix there is for gtk2.12, so knowing the gtk version is important).

Comment 27

[sam morris]

Well am using gtk 2.12.9.

Comment 28

[sam morris]

And I ran into this again with GTK+ 2.12.11. Please can someone re-open this bug?

Comment 29

[sam morris]

Oh, and xulrunner 1.9.0.1 this time.

Comment 30

[Karl Tomlinson (:karlt)]

Sam, can you indicate which steps to reproduce cause a crash for you, please?

Comment 31

[sam morris]

Unfortunately I am unable to reproduce the crash to a recipe. All I know is that Epiphany will sometimes crash with this stack trace when I close it. :(

I'll attach the exact backtrace that I got yesterday, hopefully it will help.

Comment 32

[sam morris]

Created attachment 333248 [details]
backtrace with gtk 2.12.11 and xulrunner 1.9.0.1

Comment 33

[Gwenole Beauchesne]

Hi, I don't think this issue is caused by bug #469538.

However, I looked briefly at XEMBED (through GtkPlug / GtkSocket) while debugging a problem for nspluginwrapper. It turns out Firefox never destroys the plugin window cleanly, and its not really its fault. First, Firefox never propagates NPP_SetWindow(NPP, (NPWindow){ .window = NULL }); down to the plugin. Then, DoStopPlugin() will generally delay destroy of the page window, not the plugin window. That window is destroyed at the Gdk level (through a simple g_object_unref() IIRC). However, in the best cases, that "toplevel" window destruction will trigger the destruction of the GtkSocket, but not the underlying X window.

Something important to note: GtkPlug / GtkSocket work differently depending on whether the other GtkPlug is in-process or out of process. In out-of-process case, destroying a window will destroy all subsequent windows in the hierarchy, including the plugins X windows and windows in the other process. However, in the in-process case, the X window (exposed to the plugin) is never destroyed. Nada, no call to XDestroyWindow() with that XID.

AFAIK, this is a problem for Flash that doesn't expect someone else destroying its plugin window from behind its back. It currently works in Firefox because the plugin XID is never destroyed for the lifetime of the program. However, when run through nspluginwrapper, and since I tried to respect the NPAPI specs and destroying the windows around NPP_Destroy(), it fails.

I will probably open another bug entry for this specific issue, though this is not really Firefox's fault (rather Gtk2). However, Firefox could have been cool and send NPP_SetWindow() with a NULL NPWindow::window, as mentioned in the specs. Though, Flash (even version 10) doesn't handle that case either anyway. So, we are left with a possible Gtk2 bug.

Note: I workarounded the issue at the nspluginwrapper level by forbidding propagation of WM_DELETE_EVENT (that the GtkSocket sends) + other tricks.

I am not sure I was clear enough as I was typing this away from the actual Firefox sources, but rather dumped what I had in memory. ;-)

Comment 34

[Alexander Sack]

(In reply to comment #33)
> I will probably open another bug entry for this specific issue, though this is
> not really Firefox's fault (rather Gtk2). However, Firefox could have been cool
> and send NPP_SetWindow() with a NULL NPWindow::window, as mentioned in the
> specs. Though, Flash (even version 10) doesn't handle that case either anyway.
> So, we are left with a possible Gtk2 bug.

This bug is not only about flashplugin; we saw this crash mostly with totem and other plugins; so while flash currently might not handle it, it might still be worthwhile to consider this anyway.

BTW, which "specs" are you referring to exactly?

> 
> Note: I workarounded the issue at the nspluginwrapper level by forbidding
> propagation of WM_DELETE_EVENT (that the GtkSocket sends) + other tricks.
> 
> I am not sure I was clear enough as I was typing this away from the actual
> Firefox sources, but rather dumped what I had in memory. ;-)

It made a bit sense at least :) ... thanks for your ideas on this!

Comment 35

[timeless]

yes, @nokia we learned about flash ignoring setwindow null. i had suggested it as a fix for something (in fact, quite possibly a crash w/ this signature) and then an engineer mentioned that the flash side ignored it. i was heartbroken.

Comment 36

[Wayne Mery (:wsmwk)]

gtk_style_realize is not found in crash-stats. 
Do you stilll see this problem?

https://bugs.launchpad.net/ubuntu/+source/firefox/+bug/91334 last status is WONTFIX
https://bugs.launchpad.net/ubuntu/+source/firefox/+bug/72018 is also WONTFIX

Comment 37

[Launchpad]

Piero Mazzini added the following comment to Launchpad bug report 72018:

No, thank you.
The problem is solved.

Regards,

Piero Mazzini

Il giorno 25/mag/2013, alle ore 23.40, Vseerror ha scritto:

> gtk_style_realize is not found in crash-stats. 
> Do you stilll see this problem?
> 
> https://bugs.launchpad.net/ubuntu/+source/firefox/+bug/91334 last status is WONTFIX
> https://bugs.launchpad.net/ubuntu/+source/firefox/+bug/72018 is also WONTFIX
> 
> -- 
> You received this bug notification because you are subscribed to a
> duplicate bug report (86619).
> https://bugs.launchpad.net/bugs/72018
> 
> Title:
>  MASTER Firefox Crash [@gtk_style_realize] [@nsFilePicker::Show]
> 
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/firefox/+bug/72018/+subscriptions



-- 
http://launchpad.net/bugs/72018

Comment 38

[Georg Fritzsche [:gfritzsche]]

Closing here, please comment if there are still configurations where this is relevant.