Created attachment 404338 [details] backtrace Firefox segfaults on a new profile after opening https://inbox.google.com/u/0/?pli=1 - sometimes immediately, sometimes after 1-2 minutes. Haven't seen this problem with any other websites. Anarchy was able to reproduce this issue only after switching from libav to ffmpeg, so maybe this is gst-plugins-libav related? Backtrace attached, unfortunately rip gets overwritten, so the guilty thread is not available.
I suspect I am getting the same issue, however I've been getting this to happen on numerous sites at random times. Attached is a couple bt's (one simple bt, the other threaded bt full) for the issue. I noticed one interesting thing, is after my bt run I had this output in the console window (may potentialy be the issue). Note: Only firefox is compiled with symbols, if you want anything else with, just mention them (I have been able to get it to segfault numerous times already). [NPAPI 7773] ###!!! ABORT: Aborting on channel error.: file /var/tmp/portage/www-client/firefox-38.0.1/work/mozilla-release/ipc/glue/MessageChannel.cpp, line 1584 [NPAPI 7773] ###!!! ABORT: Aborting on channel error.: file /var/tmp/portage/www-client/firefox-38.0.1/work/mozilla-release/ipc/glue/MessageChannel.cpp, line 1584 # # A fatal error has been detected by the Java Runtime Environment: # # SIGSEGV (0xb) at pc=0x00007ffff79bdfcc, pid=7773, tid=140736988382976 # # JRE version: Java(TM) SE Runtime Environment (8.0_45-b14) (build 1.8.0_45-b14) # Java VM: Java HotSpot(TM) 64-Bit Server VM (25.45-b02 mixed mode linux-amd64 compressed oops) # Problematic frame: # C [libmozalloc.so+0xfcc] mozalloc_abort(char const*)+0x1d # # Failed to write core dump. Core dumps have been disabled. To enable core dumping, try "ulimit -c unlimited" before starting Java again # # An error report file with more information is saved as: # /home/ct85711/hs_err_pid7773.log # # If you would like to submit a bug report, please visit: # http://bugreport.java.com/bugreport/crash.jsp # Redirecting call to abort() to mozalloc_abort [error occurred during error reporting , id 0xb] Redirecting call to abort() to mozalloc_abort [error occurred during error reporting , id 0xb] Redirecting call to abort() to mozalloc_abort This is sounding like maybe it's this jemalloc3, that's causing it. I will test with that turned off, and see what results I get. [ebuild R ] www-client/firefox-38.0.1::gentoo USE="dbus gmp-autoupdate gstreamer jemalloc3 jit minimal pulseaudio startup-notification system-sqlite -bindist -custom-cflags -custom-optimization -debug -hardened (-pgo) (-selinux) -system-cairo -system-icu -system-jpeg -system-libvpx {-test} -wifi" LINGUAS="-af -ar -as -ast -be -bg -bn_BD -bn_IN -br -bs -ca -cs -cy -da -de -el -en_GB -en_ZA -eo -es_AR -es_CL -es_ES -es_MX -et -eu -fa -fi -fr -fy_NL -ga_IE -gd -gl -gu_IN -he -hi_IN -hr -hu -hy_AM -id -is -it -ja -kk -km -kn -ko -lt -lv -mai -mk -ml -mr -nb_NO -nl -nn_NO -or -pa_IN -pl -pt_BR -pt_PT -rm -ro -ru -si -sk -sl -son -sq -sr -sv_SE -ta -te -th -tr -uk -vi -xh -zh_CN -zh_TW" 0 KiB
Created attachment 404436 [details] Simple bt (non threaded)
Created attachment 404438 [details] Threaded Full bt
Seems I have the similar problem. After an upgrade to firefox 38 youtube started to crash with severe memory leaking ( something like 10GB of virtual memory after a few minutes of HD video playing ). Then I noticed crashing on some other sites as well. The only thing which helps is to build firefox without gstreamer. I'm building firefox-37.0.2 now in order to check if the issue is firefox 38 specific or I should dig more towards gstreamer. By the way I don't have libav installed on my system.
I think this is a dupe of bug 543054 Looks like either updating to ffmpeg-2.6 or dropping the libav-9 patch and rebuilding fixes the problem... but I am unsure if after dropping that patch it will still work ok with even current stable libav-11.3
(In reply to Pacho Ramos from comment #5) > I think this is a dupe of bug 543054 > > Looks like either updating to ffmpeg-2.6 or dropping the libav-9 patch and > rebuilding fixes the problem... but I am unsure if after dropping that patch > it will still work ok with even current stable libav-11.3 The original bug was triggered with ffmpeg-2.6.3 installed, so im not sure if that is actually going to help resolve this...
Crashing on Youtube videos after updating to media-plugins/gst-plugins-libav-1.4.5-r1. 1.2.4-r1 works.
Good news, upgrading to ffmpeg-2.6.3 solved youtube problem for me. Firefox 37.0.2 is affected by this bug as well.
(In reply to Sasha Medvedev from comment #8) > [...] upgrading to ffmpeg-2.6.3 solved youtube problem for me. I can confirm this. I'm using firefox-38.0.1. Through ffmpeg-2.6.3 everything works fine now and the memory usage stays stable.
I'm seeing this with firefox 38.0.5 and ffmpeg-2.7.1, I've also been able to reproduce it when using Seamonkey 2.33.1-r1. Easiest way to reproduce it is by going to youtube and changing videos quickly by clicking on the next video. $ firefox (process:13411): GLib-CRITICAL **: g_slice_set_config: assertion 'sys_page_size == 0' failed console.error: bmnszmcz: Unable to apply panel style console.error: bmnszmcz: Message: TypeError: container is null Stack: style@resource://gre/modules/commonjs/toolkit/loader.js -> resource://gre/modules/commonjs/sdk/panel/utils.js:385:1 onContentReady@resource://gre/modules/commonjs/toolkit/loader.js -> resource://gre/modules/commonjs/sdk/panel/utils.js:279:7 libva info: VA-API version 0.37.0 libva info: va_getDriverName() returns 0 libva info: Trying to open /usr/lib64/va/drivers/nvidia_drv_video.so libva info: Found init function __vaDriverInit_0_37 libva info: va_openDriver() returns 0 [NPAPI 13492] ###!!! ABORT: Aborting on channel error.: file /var/tmp/portage/www-client/firefox-38.0.5/work/mozilla-release/ipc/glue/MessageChannel.cpp, line 1584 [NPAPI 13492] ###!!! ABORT: Aborting on channel error.: file /var/tmp/portage/www-client/firefox-38.0.5/work/mozilla-release/ipc/glue/MessageChannel.cpp, line 1584 Segmentation fault
I get the same thing after switching to libav. I've also been able to reproduce this on a different Gentoo machine.
firefox-bin seems stable, only building firefox from source has the problem.
According to comment 15 in https://bugzilla.mozilla.org/show_bug.cgi?id=1112371 firefox most likely doesn't offitially support gstreamer:1.0. So if anyone could test a build with gstreamer:0.10 ...
Created attachment 406114 [details] Updated mozconfig to build against gstreamer-0.10
Created attachment 406116 [details] Firefox updated to use mozconfig-v5.39
Created attachment 406118 [details] seamonkey updated to use mozconfig-v5.39
Building against gstreamer-0.10 seems to of fixed the problem. I've attached an updated mozconfig which builds against gstreamer-0.10. I wasn't sure what versions to set the minimum requires for gstreamer to be so I just used whats currently on my system(~amd64). I've also attached an updated firefox and seamonkey ebuild which uses mozconfig-v5.39.
I appreciate everyone's efforts here. some notes: 5.39 (if needed, and it likely will be) is going to be the eclass name to support firefox-39 and any other mozilla-39 packages. To bump the version of the eclass it's better to increase the 5 to 6, that way you won't end up with a conflict later. Regarding gstreamer-1.0 vs gstreamer-0.10, the comments weren't overly accurate in the mozilla bug -- gstreamer-1.0 is supported by mozilla but isn't what the binary packages are built with yet. That said, since people are having issues with gstreamer-1.0 in some cases, I've added firefox-38.1.0 and firefox-39 candidates with an additional gstreamer-0 USE flag to the mozilla overlay.
Seamonkey is effected by the same bug. Whatever fix you apply to Firefox could you please apply the same one to Seamonkey?
(In reply to Lee Trager from comment #19) > Seamonkey is effected by the same bug. Whatever fix you apply to Firefox > could you please apply the same one to Seamonkey? Yes, since the change will be in the eclass, seamonkey will also get the new flag. That said, seamonkey upstream is having issues and not releasing, so this likely won't occur any time soon in the natural order of upgrades. I'll query Poly-C about making a change to the existing version(s).
Same issue here with ff 39 and ffmpeg 2.6.2 and also ffmpeg 2.7.1. Re-emerging firefox with gstreamer-0 seems to have fixed it
If you feel I have closed your bug and it is still a current issue, please reopen and update it completely. We will not work bugs that have no ebuild in tree any longer or can not be reproduced with a current system. Thank You for your support and understanding The Mozilla Team
