Closed Bug 1205199 Opened 4 years ago Closed 4 years ago

flash plugin-container crashes whole firefox

Categories

(Core :: Plug-ins, defect, critical)

40 Branch
x86_64
Linux
defect
Not set
critical

Tracking

()

RESOLVED FIXED
mozilla47
Tracking Status
firefox43 --- disabled
firefox46 blocking fixed
firefox47 + fixed

People

(Reporter: pasik, Assigned: karlt)

References

Details

(Keywords: crash, flashplayer, topcrash-linux)

Attachments

(3 files)

User Agent: Mozilla/5.0 (X11; Fedora; Linux x86_64; rv:40.0) Gecko/20100101 Firefox/40.0
Build ID: 20150827075926

Steps to reproduce:

While browsing the web normally current firefox 40 seems to crash a lot. It seems to happen on random websites, but it happens quite often for me, usually many times per day. No simple way to reproduce. Except just using firefox for a day or so..

I'm running Firefox 40 on Linux Fedora 22 x86_64. Currently it's firefox-40.0.3-1.fc22.x86_64




Actual results:

firefox crashes often, sometimes many crashes per day, with for example the following messages in /var/log/messages:

Sep  3 00:58:56 localhost kernel: do_trap: 198 callbacks suppressed
Sep  3 00:58:56 localhost kernel: traps: firefox[2937] trap stack segment ip:7f1d8cc97fb0 sp:7ffd70e228e0 error:0 in libgtk-3.so.0.1600.6[7f1d8c912000+6da000]
Sep  3 00:58:56 localhost audit: <audit-1701> auid=1000 uid=1000 gid=1000 ses=1 subj=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 pid=2937 comm="firefox" exe="/usr/lib64/firefox/firefox" sig=7 
Sep  3 00:58:59 localhost audit: <audit-1701> auid=1000 uid=1000 gid=1000 ses=1 subj=unconfined_u:unconfined
_r:mozilla_plugin_t:s0-s0:c0.c1023 pid=3598 comm="Chrome_ChildThr" exe="/usr/lib64/firefox/plugin-container" sig=11
Sep  3 00:58:59 localhost kernel: Chrome_ChildThr[3598]: segfault at 0 ip 000055645838fd4a sp 00007f564f543470 error 6 in plugin-container[556458388000+39000]


When running in GDB I get this:

Program received signal SIGBUS, Bus error.
gtk_socket_filter_func (gdk_xevent=0x7fffffffc1e0, event=0x7fffd1c20860, 
    data=0x7fff7aef7510) at gtksocket.c:1371
1371      if (private->plug_widget)
(gdb)

I'll attach full backtrace aswell.



Expected results:

firefox doesn't crash (even if flash plugin crashes) and works normally.
Severity: normal → major
OS: Unspecified → Linux
Hardware: Unspecified → x86_64
I've also reported this issue on fedora bugzilla:
https://bugzilla.redhat.com/show_bug.cgi?id=1259525
Just got the plugin-container crash once again, when trying to click play on a flash video on a web page:

Program received signal SIGBUS, Bus error.
gtk_socket_filter_func (gdk_xevent=0x7fffffffc1e0, event=0x7fffb44cb790, data=0x7fff9ee76030)
    at gtksocket.c:1371
1371	  if (private->plug_widget)
(gdb)


dmesg:
[58832.569404] Chrome_ChildThr[10319]: segfault at 0 ip 000055e2d93a4d4a sp 00007f7d5f343470 error 6 in plugin-container[55e2d939d000+39000]

I'll attach full GDB backtrace.
Keywords: crash
It seems the version of Firefox built by Mozilla (the official binary) works better, and I haven't gotten crashes with the stock version yet. So it seems to be a bug specific to Fedora build of Firefox.
Running Firefox 41.0.2 (Fedora 22 build) now, and it seems to crash a lot too.. 

It looks like the GTK3 build of Firefox (in Fedora) is not compatible with adobe flash plugin, and causes a lot of crashes..
It might not be GTK3 related.
With 42.0 on a different distro, but also amd64 arch, built still against GTK2, flash crashes a lot too.

I don't have a backtace, but the start of the log line looks similar: [kernel] Chrome_ChildThr[31319]: segfault at 0 ip 00000000004097fb sp 00007f78b16fe510 error 6 in plugin-container[400000+5b000]
...I found something, that might matter: on one of linuxfromscratch pages regarding firefox, there's a note >=firefox-40 needing to be built with bundled cairo, due to unspecified crashes.
One of Fedora bugs mentions something similar in the passing (and states plans of switching to bundled cairo too)...

If that's really the case here, I'll be once again "impressed" by cooperation between these two upstreams.
(In reply to Rafał Mużyło from comment #7)
> ...I found something, that might matter: on one of linuxfromscratch pages
> regarding firefox, there's a note >=firefox-40 needing to be built with
> bundled cairo, due to unspecified crashes.
> One of Fedora bugs mentions something similar in the passing (and states
> plans of switching to bundled cairo too)...
> 
> If that's really the case here, I'll be once again "impressed" by
> cooperation between these two upstreams.

Interesting finding. Can you please link the Fedora bugzilla you mentioned?

Thanks.
(In reply to pasik from comment #8)

Not sure if it was eventually implemented, but see 
https://bugzilla.redhat.com/show_bug.cgi?id=1253086.
Hi,

Do you still have this problem? Please test this with the latest release Firefox 43.
Flags: needinfo?(pasik)
My Firefox 43.0.1 crashes on Arch64

[114146.365860] traps: firefox[1193] trap stack segment ip:7ffa84571780 sp:7ffc03d26c20 error:0 in libgtk-3.so.0.1800.6[7ffa841dd000+70f000]
[114148.320020] Chrome_ChildThr[3039]: segfault at 0 ip 000055f9c007a38a sp 00007fd202efe480 error 6 in plugin-container[55f9c0072000+6b000]
The crashes for me began two weeks ago, after i deleted my very old firefox profile and creating a new one. Today i realized, that firefox no longer asks me for activate flash. In the Addon settings, flash was on "Always active". It was on "Ask to active" before creating the new profile. I think that's why the error is not noticed before, because I very rarely use(activate) flash.

It is very difficult to recreate the crash. It happened only once or twice a week. Yesterday the paypal webseite was the trigger. I hope I was able to help a little.
Component: Untriaged → Plug-ins
Product: Firefox → Core
Yep, Fedora 22 (gtk3) build of Firefox 43 crashes aswell, just got these dmesg messages and firefox crashed while opening youtube.com url:

[68091.856080] traps: firefox[3365] trap stack segment ip:7ff502e0afe0 sp:7fffbd27c520 error:0 in libgtk-3.so.0.1600.7[7ff502a85000+6da000]

[68097.425189] Chrome_ChildThr[20333]: segfault at 0 ip 0000564be7a7f796 sp 00007f3834ffe470 error 6 in plugin-container[564be7a77000+3d000]
Flags: needinfo?(pasik)
(In reply to David Stommel from comment #13)
> It is very difficult to recreate the crash. It happened only once or twice a
> week. Yesterday the paypal webseite was the trigger. I hope I was able to
> help a little.

I am getting more or less exactly the same crash on Arch 64. It is difficult find a reliable way to reproduce the bug, but it only happens AFTER using flash in some way. Using flash does not always lead to the crash, however.
(In reply to Rafał Mużyło from comment #9)
> (In reply to pasik from comment #8)
> 
> Not sure if it was eventually implemented, but see 
> https://bugzilla.redhat.com/show_bug.cgi?id=1253086.

It will be see https://bugzilla.redhat.com/show_bug.cgi?id=1253086#c23
> We're going to switch to mozilla in-tree cairo in next release.

Has anyone tried reproducing this bug in Firefox 46.0a1? And, Pasik, what is your Flash version? If the "Plugins" tab of the add-ons manager doesn't display it, try hovering your mouse over the plugin name.


FWIW, with the SeaMonkey linux-x86_64 trunk builds from ftp.mozilla.org I'm experiencing extremely rare crashes, even when I've been using Flash: my latest crash ID in about:crashes ends in 20151113. I don't know if the fact that I install every new nightly I see (which may mean a browser restart once a day when the releng system isn't broken down) is relevant. According to about:addons, my Flash plugin currently calls itself "Shockwave Flash 11.2.202.559". I got it from the Packman repository for openSUSE Leap 42.1, http://ftp.halifax.rwth-aachen.de/packman/suse/openSUSE_Leap_42.1/
Severity: major → critical
Flags: needinfo?(pasik)
Keywords: flashplayer
My flash-plugin info:

Shockwave Flash

    File: libflashplayer.so
    Path: /usr/lib64/flash-plugin/libflashplayer.so
    Version: 11.2.202.554
    State: Enabled
    Shockwave Flash 11.2 r202
Flags: needinfo?(pasik)
Status: UNCONFIRMED → NEW
Ever confirmed: true
I've been using flash with GTK3 builds for months now and I don't have any crashes. Maybe because I use flash 20.0.
Assignee: nobody → karlt
Status: NEW → ASSIGNED
(In reply to AnAkkk from comment #18)
> I've been using flash with GTK3 builds for months now and I don't have any
> crashes. Maybe because I use flash 20.0.

Where do you download that from? Do you use the PPAPI->NPAPI bridge?
(In reply to Anthony Jones (:kentuckyfriedtakahe, :k17e) from comment #19)
> (In reply to AnAkkk from comment #18)
> > I've been using flash with GTK3 builds for months now and I don't have any
> > crashes. Maybe because I use flash 20.0.
> 
> Where do you download that from? Do you use the PPAPI->NPAPI bridge?

Exactly, I am using freshplayerplugin. I am using ArchLinux, so I just need to download freshplayerplugin and chromium-pepper-flash-standalone from the AUR. It is of course available in other distributions like Ubuntu.

https://github.com/i-rinat/freshplayerplugin
Would you be able to review this, please, Andrew?
If not, just let me know and I'll find another reviewer.
Thanks!
I suspect this problem did not show up with GTK2 because
_gtk_socket_windowing_filter_func returns early when socket->plug_widget is
non-zero, which would be typical when the socket is deleted by jemalloc.

GTK3 however has additional indirection in its test for early return from gtk_socket_filter_func when socket->priv->plug_widget.  Values set on priv on delete of the socket would usually lead to a bus error for an invalid memory address.
Comment on attachment 8718197 [details]
MozReview Request: bug 1205199 keep the socket alive as long as the plug window r?acomminos

https://reviewboard.mozilla.org/r/34461/#review31165

Looks good to me! This seems safer than manually removing socket native event filters when the plug window is destroyed.
Attachment #8718197 - Flags: review?(andrew) → review+
I'm guessing this should also fix the issues with event filter functions triggering a SIGBUS in bug 1239962? The best symbolicated stack trace to gtk_socket_filter_func suggests it would.
Duplicate of this bug: 1239962
(In reply to Andrew Comminos [:acomminos] from comment #24)
> This seems safer than manually removing socket native
> event filters when the plug window is destroyed.

Yes, the filter function pointer is not available to destroy it, and getting a notification of GdkWindow destruction would require putting it in a widget, which is more messing with GTK's window than I would like to do.

(In reply to Andrew Comminos [:acomminos] from comment #25)
> I'm guessing this should also fix the issues with event filter functions
> triggering a SIGBUS in bug 1239962? The best symbolicated stack trace to
> gtk_socket_filter_func suggests it would.

Yes, thanks!
https://hg.mozilla.org/mozilla-central/rev/0ed4561d22d1
Status: ASSIGNED → RESOLVED
Closed: 4 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla47
Comment on attachment 8718197 [details]
MozReview Request: bug 1205199 keep the socket alive as long as the plug window r?acomminos

Approval Request Comment
[Feature/regressing bug #]: Logstanding GTK bug, but consequences are worse with GTK3.
[User impact if declined]: crashes with windowed plugins.
[Describe test coverage new/current, TreeHerder]:
There are many existing plugin tests.  We don't have STR, which may hint at why the tests didn't notice this bug.
[Risks and why]: small patch; not significant risk, but possible leak I guess if I've missed something.
[String/UUID change made/needed]: none.
Attachment #8718197 - Flags: approval-mozilla-aurora?
Tracking and marking affected for 46 since this gets worse with gtk3
Comment on attachment 8718197 [details]
MozReview Request: bug 1205199 keep the socket alive as long as the plug window r?acomminos

Hard to tell if this has worked since we don't have STR, but let's uplift the fix to aurora and see if flash related crashes decrease.
Attachment #8718197 - Flags: approval-mozilla-aurora? → approval-mozilla-aurora+
Bug 1239962 was marked as a duplicate of this bug, and since it was also a blocker for 46 as a bad topcrash in linux, I'll track this as a blocker as well.
Well, it's marked as fixed in f46, yet in the meanwhile it became completely broken in f45.

So, OK, it might be a different bug, just with similar looking result (and pretty much the same message ("Chrome_ChildThr...")).

The crash now happens in seemingly random places, now not even related to flash use (as the crash happens even despite FlashBlock).

I can't quite find the common denominator of the sites where the crash happens.
For whoever ends up on this thread when Googling for similar error messages to 

"traps: firefox[3365] trap stack segment ip:7ff502e0afe0 sp:7fffbd27c520 error:0 in libgtk-3.so.0.1600.7"
or 
"Chrome_ChildThr[20333]: segfault at 0 ip 0000564be7a7f796 sp 00007f3834ffe470 error 6 in plugin-container"

I had an issue with Firefox crashing for several months, started sometime in January 2016. I wasted many hours on forums trying to figure out the root case. I tried 10+ different solutions I found, including creating new profiles, compiling my own Firefox from source code, disabling all add-ons and plugins. Nothing did it, my Firefox kept crashing at the most random moments. Once it would start crashing, the only way to get rid of subsequent crash would be to reboot the machine. Then, Firefox would be okay for about 1-2 hours, before a new crash happened.

It was driving me crazy since my workflow heavily depends on Firefox (oh, BTW my chromium-browser would crash similarly, with similar error in syslog). And I finally found a solution that fixed it for me...

memtest86

It turned out my RAM bar was bad. Literally, my hardware was crashing Firefox. I had had hard disk failure before, but never RAM failure, so I didn't think about that earlier.

I ran memtest86, got 200+ errors, swapped the RAM. I've been running Firefox for 10 days no, for 12+ hours per day working heavily with many tabs including Flash players. Not a single crash... My nightmares are gone, I can finally sleep at night. I hope this helps someone.
(In reply to gapar2 from comment #37)
> For whoever ends up on this thread when Googling for similar error messages
> to 
> 
> "traps: firefox[3365] trap stack segment ip:7ff502e0afe0 sp:7fffbd27c520
> error:0 in libgtk-3.so.0.1600.7"
> or 
> "Chrome_ChildThr[20333]: segfault at 0 ip 0000564be7a7f796 sp
> 00007f3834ffe470 error 6 in plugin-container"
> 
> I had an issue with Firefox crashing for several months, started sometime in
> January 2016. I wasted many hours on forums trying to figure out the root
> case. I tried 10+ different solutions I found, including creating new
> profiles, compiling my own Firefox from source code, disabling all add-ons
> and plugins. Nothing did it, my Firefox kept crashing at the most random
> moments. Once it would start crashing, the only way to get rid of subsequent
> crash would be to reboot the machine. Then, Firefox would be okay for about
> 1-2 hours, before a new crash happened.
> 
> It was driving me crazy since my workflow heavily depends on Firefox (oh,
> BTW my chromium-browser would crash similarly, with similar error in
> syslog). And I finally found a solution that fixed it for me...
> 
> memtest86
> 
> It turned out my RAM bar was bad. Literally, my hardware was crashing
> Firefox. I had had hard disk failure before, but never RAM failure, so I
> didn't think about that earlier.
> 
> I ran memtest86, got 200+ errors, swapped the RAM. I've been running Firefox
> for 10 days no, for 12+ hours per day working heavily with many tabs
> including Flash players. Not a single crash... My nightmares are gone, I can
> finally sleep at night. I hope this helps someone.

Firefox (v48.0) crashed again on 2016-08-22 with the error message:
Chrome_ChildThr[8764]: segfault at 0 ip 00007f9f30af9f73 sp 00007f9f221fe3c0 error 6 in plugin-container[7f9f30af1000+3d000]

I hope this attract due attention.
(In reply to myuller.aleck@ya.ru from comment #38)
> (In reply to gapar2 from comment #37)
> > For whoever ends up on this thread when Googling for similar error messages
> > to 
> > 
> > "traps: firefox[3365] trap stack segment ip:7ff502e0afe0 sp:7fffbd27c520
> > error:0 in libgtk-3.so.0.1600.7"
> > or 
> > "Chrome_ChildThr[20333]: segfault at 0 ip 0000564be7a7f796 sp
> > 00007f3834ffe470 error 6 in plugin-container"
> > 
> > I had an issue with Firefox crashing for several months, started sometime in
> > January 2016. I wasted many hours on forums trying to figure out the root
> > case. I tried 10+ different solutions I found, including creating new
> > profiles, compiling my own Firefox from source code, disabling all add-ons
> > and plugins. Nothing did it, my Firefox kept crashing at the most random
> > moments. Once it would start crashing, the only way to get rid of subsequent
> > crash would be to reboot the machine. Then, Firefox would be okay for about
> > 1-2 hours, before a new crash happened.
> > 
> > It was driving me crazy since my workflow heavily depends on Firefox (oh,
> > BTW my chromium-browser would crash similarly, with similar error in
> > syslog). And I finally found a solution that fixed it for me...
> > 
> > memtest86
> > 
> > It turned out my RAM bar was bad. Literally, my hardware was crashing
> > Firefox. I had had hard disk failure before, but never RAM failure, so I
> > didn't think about that earlier.
> > 
> > I ran memtest86, got 200+ errors, swapped the RAM. I've been running Firefox
> > for 10 days no, for 12+ hours per day working heavily with many tabs
> > including Flash players. Not a single crash... My nightmares are gone, I can
> > finally sleep at night. I hope this helps someone.
> 
> Firefox (v48.0) crashed again on 2016-08-22 with the error message:
> Chrome_ChildThr[8764]: segfault at 0 ip 00007f9f30af9f73 sp 00007f9f221fe3c0
> error 6 in plugin-container[7f9f30af1000+3d000]
> 
> I hope this attract due attention.

Well, memtest86 run afterwards and showed:
Test Std
Pass 2
Errors 0
You need to log in before you can comment on or make changes to this bug.