MASTER (variant) Firefox Crash [@gtk_style_realize]

[Sitsofe Wheeler]

NOTE: Please don't merge with main MASTER

Updated Description with testcase::

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.

Expected result:
Video to always start playing (network conditions permitted). Theme change to happen without firefox crashing.

Actual result:
Video eventually stops playing. When the video is hung, theme change causes firefox to crash.

How reproducible is the problem:
The problem is reproducible 100% of the time.

Version information:
Ubuntu Feisty
firefox 2.0.0.2+1-0ubuntu1
totem-mozilla 2.17.92-0ubuntu4
totem-gstreamer 2.17.92-0ubuntu4

ProblemType: Crash
Architecture: i386
CrashCounter: 1
Date: Sun Mar 11 09:21:03 2007
DistroRelease: Ubuntu 7.04
ExecutablePath: /usr/lib/firefox/firefox-bin
Package: firefox 2.0.0.2+1-0ubuntu1
PackageArchitecture: i386
ProcCmdline: /usr/lib/firefox/firefox-bin
ProcCwd: /home/sits
ProcEnviron:
 SHELL=/bin/bash
 PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games
 LANG=en_GB.UTF-8
Signal: 11
SourcePackage: firefox
StacktraceTop:
 __kernel_vsyscall ()
 raise () from /lib/tls/i686/cmov/libpthread.so.0
 nsProfileLock::FatalSignalHandler (signo=-1210183692)

 ?? () from /usr/lib/libgtk-x11-2.0.so.0
Uname: Linux galvatron 2.6.20-9-generic #2 SMP Mon Feb 26 03:01:44 UTC 2007 i686 GNU/Linux
UserGroups: adm admin audio cdrom dialout dip floppy lpadmin netdev plugdev powerdev scanner video

[Aleksej (aleksejrs)]

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.

[Adam Guthrie (ispiked)]

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

[c7d2f5c8667d26fffd5e7772d632c76d (c7d2f5c8667d26fffd5e7772d632c76d-deactivatedaccount)]

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

[Reinout van Schouwen (reinout-gmail)]

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

[Timeless-bemail (timeless-bemail)]

<email address hidden>: that's nice. are you volunteering to work on it?

[Alexander Sack (asac)]

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

[Aleksej (aleksejrs)]

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

[Alexander Sack (asac)]

I'll give it a try. stay tuned.

[Alexander Sack (asac)]

Created attachment 257133
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?

[Alexander Sack (asac)]

Comment on attachment 257133
maybe this (1.8 branch)

this patch breaks other plugins.

[Alexander Sack (asac)]

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.

[Sitsofe Wheeler (sitsofe)]

Binary package hint: firefox

Description of the problem:
After watching four or five getamac adverts on the apple website I tried to quit firefox and while the "are you sure you want to close the tabs" dialog was appearing firefox crashed.

Steps to reproduce:
1. Start firefox .
2. Visit
http://www.apple.com/getamac/ads/
3. Let the video play for a few seconds.
4. While that video is playing click on another video that you have yet to watch at the bottom of the screen.
5. Go to step 3 a few times.
6. Open another tab and try and quit firefox by using the X at the top right hand corner of the window.

Expected results:
Newly clicked videos to always keep playing. Firefox to quit without crashing.

Actual result:
Eventually the video area will be perpetually black. Quitting firefox results in a a crash.

How reproducible is the problem:
Haven't tried to reproduce it yet.

Version information:
Ubuntu Feisty
firefox 2.0.0.2+1-0ubuntu1
totem-mozilla 2.17.92-0ubuntu4
totem-gstreamer 2.17.92-0ubuntu4

ProblemType: Crash
Architecture: i386
CrashCounter: 1
Date: Sun Mar 11 09:21:03 2007
DistroRelease: Ubuntu 7.04
ExecutablePath: /usr/lib/firefox/firefox-bin
Package: firefox 2.0.0.2+1-0ubuntu1
PackageArchitecture: i386
ProcCmdline: /usr/lib/firefox/firefox-bin
ProcCwd: /home/sits
ProcEnviron:
 SHELL=/bin/bash
 PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games
 LANG=en_GB.UTF-8
Signal: 11
SourcePackage: firefox
StacktraceTop:
 __kernel_vsyscall ()
 raise () from /lib/tls/i686/cmov/libpthread.so.0
 nsProfileLock::FatalSignalHandler (signo=-1210183692)

 ?? () from /usr/lib/libgtk-x11-2.0.so.0
Uname: Linux galvatron 2.6.20-9-generic #2 SMP Mon Feb 26 03:01:44 UTC 2007 i686 GNU/Linux
UserGroups: adm admin audio cdrom dialout dip floppy lpadmin netdev plugdev powerdev scanner video

[Sitsofe Wheeler (sitsofe)]

The following was in ~/.xsession-errors in the run up to the crash:

** Message: mSrc: http://movies.apple.com/movies/us/apple/getamac/giftexchange_480x376.mov
** Message: mCache: 1
** Message: mControllerHidden: 0
** Message: mShowStatusbar: 0
** Message: mHidden: 0
** Message: mAudioOnly: 0
** Message: mAutostart: 1, mRepeat: 0
** Message: mHref:
** Message: mTarget:
** Message: Launching: /usr/lib/totem/totem-plugin-viewer --plugin-type narrowspace --user-agent Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.1.2) Gecko/20061201 Firefox/2.0.0.2 (Ubuntu-feisty) --mimetype video/quicktime
** Message: Viewer spawned, PID 8747
** Message: GetValue variable 14 (e)
** Message: Initial window set, XID 3400e72 size 480x376
** Message: No viewer proxy yet, deferring SetWindow
** Message: Viewer DBus interface name is 'org.gnome.totem.PluginViewer_8747'
** Message: NameOwnerChanged old-owner '' new-owner ':1.52'
** Message: Viewer now connected to the bus
** Message: ViewerSetup
** Message: Calling SetWindow
** Message: NameOwnerChanged old-owner '' new-owner ':1.52'
** Message: Already have owner, why are we notified again?
Viewer: SetWindow XID 54529650 size 480:376
** Message: Viewer state: STOPPED
** Message: SetWindow reply
** Message: ViewerReady
** Message: IsSchemeSupported scheme 'http': yes
** Message: totem_embedded_open_internal 'fd://0' is-browser-stream 1
** Message: BEFORE _open
** Message: AFTER _open (ret: 1)
** Message: Viewer state: PLAYING
** Message: OpenStream reply

(Gecko:8562): Gdk-CRITICAL **: gdk_colormap_get_screen: assertion `GDK_IS_COLORMAP (cmap)' failed

(Gecko:8562): GLib-GObject-CRITICAL **: g_object_ref: assertion `G_IS_OBJECT (object)' failed

(Gecko:8562): Gdk-CRITICAL **: gdk_colormap_get_visual: assertion `GDK_IS_COLORMAP (colormap)' failed
checking for valid crashreport now

[Hilario J. Montoliu (hjmf) (hmontoliu)]

Thank you Sitsofe for submitting this crash report.

Retrace done. Marking as mt-confirm for further analysis, but at first sight this looks a known bug that should be fixed with the last totem upgrade in fesity (check bug #72018)

[Sitsofe Wheeler (sitsofe)]

Re known bug #72018 :
I know of that bug fairly well. However:

totem (2.17.92-0ubuntu4) feisty; urgency=low

  * debian/control.in:
    - don't Build-Depends on libxxf86vm-dev, the screen resizing is confusing
  * debian/patches/30_dlopen_noremove_dbus_glib.dpatch:
    - patch from Alexander Sack updated for the feisty version,
      fix "totem plugin causes frequent gecko
      crashes because NPPVpluginKeepLibraryInMemory is broke

[Sitsofe Wheeler (sitsofe)]

By the way who does this bug needinfo from?

[Hilario J. Montoliu (hjmf) (hmontoliu)]

> I know of that bug fairly well

That's why I didn't mark as dup directly, I want asac to look into it

> By the way who does this bug needinfo from?

https://wiki.ubuntu.com/MozillaTeam/Bugs/States

[Alexander Sack (asac)]

As pointed out, this bug should be now gone as we worked around broken gecko plugin code in totem. Closing.

[Alexander Sack (asac)]

ah ... ok now I see. You have latest totem, but still crash?

Please reproduce this and give us instructions. I tried to reproduce, but didn't get a crash.

[Sitsofe Wheeler (sitsofe)]

Hilario:
> That's why I didn't mark as dup directly
You were two steps ahead of me : )

Alexander:
> You have latest totem, but still crash?
Bingo!

It's an absolute pain in the neck to reproduce this bug but while trying to reproduce a different totem mozilla plugin bug .I have now triggered this problem twice more since originally filing this bug. The steps are unreliable and will not produce the problem straight away but something in these steps is triggering the problem:

Steps to reproduce:
1. Visit
http://www.apple.com/getamac/ads/
2. Repeatedly watch videos until they stop playing in the totem mozilla plugin.
3. In a new tab visit:
http://www.bloomberg.com/tvradio/tv/index.html
4. Click on "Watch now" and a new window
5. The video should become stuck. Try seeking in this video, attempting to watch mac videos in the the other window and generally opening and closing other browser tabs.
6. In a window that has more than one tab open in it click the X.

If the problem is going to happen you will receive a crash at this stage. If you don't then try repeating step 6. It may help if the totem-mozilla plugin crashes while attempting to watch the Bloomberg TV page.

I will attempt to refine these steps but don't hold your breath. The problem is highly intermittent thus far...

[Sitsofe Wheeler (sitsofe)]

OK I've got steps that reproduce this problem 100% of the time.

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.

Expected result:
Video to always start playing (network conditions permitted). Theme change to happen without firefox crashing.

Actual result:
Video eventually stops playing. When the video is hung, theme change causes firefox to crash.

How reproducible is the problem:
The problem is reproducible 100% of the time.

[Alexander Sack (asac)]

On Sun, Mar 11, 2007 at 04:09:14PM -0000, Sitsofe Wheeler wrote:
> Hilario:
> > That's why I didn't mark as dup directly
> You were two steps ahead of me : )
>
> Alexander:
> > You have latest totem, but still crash?
> Bingo!
>
> It's an absolute pain in the neck to reproduce this bug but while trying
> to reproduce a different totem mozilla plugin bug .I have now triggered
> this problem twice more since originally filing this bug. The steps are
> unreliable and will not produce the problem straight away but something
> in these steps is triggering the problem:
>
> Steps to reproduce:
> 1. Visit
> http://www.apple.com/getamac/ads/
> 2. Repeatedly watch videos until they stop playing in the totem mozilla plugin.
> 3. In a new tab visit:
> http://www.bloomberg.com/tvradio/tv/index.html
> 4. Click on "Watch now" and a new window
do you mean
4. Click on "Watch now" and in new window ?

> 5. The video should become stuck. Try seeking in this video, attempting to watch mac videos in the the other window and generally opening and closing other browser tabs.
> 6. In a window that has more than one tab open in it click the X.

has this window been playing totem videos or not?

>
> If the problem is going to happen you will receive a crash at this
> stage. If you don't then try repeating step 6. It may help if the totem-
> mozilla plugin crashes while attempting to watch the Bloomberg TV page.
>
> I will attempt to refine these steps but don't hold your breath. The
> problem is highly intermittent thus far...
>

thanks

 - Alexander

[Alexander Sack (asac)]

On Sun, Mar 11, 2007 at 04:42:29PM -0000, Sitsofe Wheeler wrote:
> OK I've got steps that reproduce this problem 100% of the time.
>
> 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.
>
> Expected result:
> Video to always start playing (network conditions permitted). Theme change to happen without firefox crashing.
>
> Actual result:
> Video eventually stops playing. When the video is hung, theme change causes firefox to crash.
>
> How reproducible is the problem:
> The problem is reproducible 100% of the time.
>

OK thanks ... will try.

 - Alexander

[Sitsofe Wheeler (sitsofe)]

Still here with
totem 2.18.0-0ubuntu1
totem-gstreamer 2.18.0-0ubuntu1
totem-mozilla 2.18.0-0ubuntu1

[John Vivirito (gnomefreak)]

Sitsofe, if its still happening can you please attach the crash log so we can see what else could be causing this?

[Sitsofe Wheeler (sitsofe)]

John,

With the new apport this isn't as easy as you might hope. How does one take a crash log and not force it into a new bug report? Do you just want the output in /var/crash/ gziped and uploaded?

[Alexander Sack (asac)]

On Tue, Mar 13, 2007 at 01:24:43PM -0000, John Vivirito wrote:
> Sitsofe, if its still happening can you please attach the crash log so
> we can see what else could be causing this?
>

I can reproduce it ... sad that there are apparently other conditions
that lead to not properly destructed gtk native windows.

IMO, totem plugin code should be completely rewritten based on mozilla
templates.

Anyway, we can keep all those gtk_style_realize bugs merged for
now. But lets keep this unmerged.

 - Alexander

[Alexander Sack (asac)]

On Tue, Mar 13, 2007 at 02:53:46PM -0000, Sitsofe Wheeler wrote:
> John,
>
> With the new apport this isn't as easy as you might hope. How does one
> take a crash log and not force it into a new bug report? Do you just
> want the output in /var/crash/ gziped and uploaded?
>

install firefox-dbg, and -gdb package for libgtk ... as well as
libc. then go and follow instructions at:

https://wiki.ubuntu.com/MozillaTeam/Bugs?highlight=%28mozillateam%29#head-c576e78d92cb3c959c271158b6ace98be835de83

You don't need to do this, because I can reproduce. But if you do it
would be nice.

 - Alexander

[Sitsofe Wheeler (sitsofe)]

Here's a log with a backtrace in it.

[Sitsofe Wheeler (sitsofe)]

(PS this bug is still marked as a dup of bug #72018 )

[Alexander Sack (asac)]

On Tue, Mar 13, 2007 at 11:16:35PM -0000, Sitsofe Wheeler wrote:
> *** This bug is a duplicate of bug 72018 ***
>
> (PS this bug is still marked as a dup of bug #72018 )
>

Yes thats ok. The bug is still not closed as your variant still applies.

 - Alexander

[Alexander Sack (asac)]

i reconsidered. Will keep this separate to investigate.

[c7d2f5c8667d26fffd5e7772d632c76d (c7d2f5c8667d26fffd5e7772d632c76d-deactivatedaccount)]

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

[Alexander Sack (asac)]

(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.

[Todd Whiteman (toddw)]

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

[John Vivirito (gnomefreak)]

I am unable to reproduce this on gutsy
firefox=2.0.0.4+2-0ubuntu2
totem=2.19.4-0ubuntu3
totem-mozilla=2.19.4-0ubuntu3
totem-xine=2.19.4-0ubuntu3

Im gonna test with totem-gstreamer but iirc this was reproduible in feisty with -xine and -gs

[John Vivirito (gnomefreak)]

also unable to reproduce with totem-gstreamer=2.19.4-0ubuntu3.

the theme prefferces freeze before the video freezes i will keep testing this to see if i can get it to happen.

[John Vivirito (gnomefreak)]

Filied a bug on the theme issue im having will test more once fixed
bug #122330

[Alexander Sack (asac)]

On Tue, Jun 26, 2007 at 04:11:06PM -0000, John Vivirito wrote:
> Filied a bug on the theme issue im having will test more once fixed
> bug #122330
>

I still see this variant crash ... so nothing improved (as expected).

 - Alexander

[Sitsofe Wheeler (sitsofe)]

Reproduced on Gutsy.

Version information:
totem-gstreamer 2.19.90-0ubuntu3
totem-mozilla 2.19.90-0ubuntu3
firefox 2.0.0.6+2-0ubuntu3

[Alexander Sack (asac)]

On Fri, Aug 31, 2007 at 07:50:21PM -0000, Sitsofe Wheeler wrote:
> Reproduced on Gutsy.
>
> Version information:
> totem-gstreamer 2.19.90-0ubuntu3
> totem-mozilla 2.19.90-0ubuntu3
> firefox 2.0.0.6+2-0ubuntu3
>

there has been a checkin on trunk that might have changed this
behaviour a bit. Can you test that? We can probably bring up bits for
such a test somewhere ... just let me know.

 - Alexander

[Sitsofe Wheeler (sitsofe)]

Alexander:
OK. What do I add to test the potential fix?

[Reed Loden (reed)]

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

[Todd Whiteman (toddw)]

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)

[Alexander Sack (asac)]

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

Closing bug.

[Alexander Sack (asac)]

verified that its fixed in firefox 3 beta 3.

[Alexander Sack (asac)]

firefox 2 most likely wont see a fix. setting status accordingly.

Thanks all for your patience. firefox 3 will be the default browser in hardy.

 - Alexander

[c7d2f5c8667d26fffd5e7772d632c76d (c7d2f5c8667d26fffd5e7772d632c76d-deactivatedaccount)]

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

[c7d2f5c8667d26fffd5e7772d632c76d (c7d2f5c8667d26fffd5e7772d632c76d-deactivatedaccount)]

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.

[Sam Morris (yrro)]

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

[Sam Morris (yrro)]

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

[Sam Morris (yrro)]

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

[Reinout van Schouwen (reinout-gmail)]

Reopening bug as requested.

[Timeless-bemail (timeless-bemail)]

reclosing. <email address hidden>: don't reopen bugs without getting people to specify versions.

<email address hidden>: don't complain about xulrunner 1.9 beta 5 when the current release of gecko is 1.9 <final>.

<email address hidden>: 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.

[c7d2f5c8667d26fffd5e7772d632c76d (c7d2f5c8667d26fffd5e7772d632c76d-deactivatedaccount)]

@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.

[Timeless-bemail (timeless-bemail)]

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).

[Sam Morris (yrro)]

Well am using gtk 2.12.9.

[Sam Morris (yrro)]

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

[Sam Morris (yrro)]

Oh, and xulrunner 1.9.0.1 this time.

[Karlt (karlt)]

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

[Sam Morris (yrro)]

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.

[Sam Morris (yrro)]

Created attachment 333248
backtrace with gtk 2.12.11 and xulrunner 1.9.0.1

[Gb-public (gb-public)]

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. ;-)

[Alexander Sack (asac)]

(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!

[Timeless-bemail (timeless-bemail)]

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.

[Vseerror (vseerror)]

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

[Feedback-launchpad (feedback-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

[Georg-fritzsche (georg-fritzsche)]

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