Already reported this on Mozilla's bugtracker https://bugzilla.mozilla.org/show_bug.cgi?id=1304355 , not realizing, Gentoo has it's own patchset, which *might* cause the problem. I closed the bug there as INVALID for now. Setting severity to critical here, following Mozilla's classification. The report there: User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:48.0) Gecko/20100101 Firefox/48.0 Build ID: 20160919030455 Steps to reproduce: Create new user account, start firefox. Actual results: Program received signal SIGSEGV, Segmentation fault. 0x00007fefe404db5a in gfxFontUtils::DecodeFontName(char const*, int, unsigned int, unsigned int, unsigned int, nsAString_internal&) () from /usr/lib64/firefox/libxul.so (gdb) bt #0 0x00007fefe404db5a in gfxFontUtils::DecodeFontName(char const*, int, unsigned int, unsigned int, unsigned int, nsAString_internal&) () from /usr/lib64/firefox/libxul.so #1 0x00007fefe4050eb9 in gfxFontUtils::ReadNames(char const*, unsigned int, unsigned int, int, int, nsTArray<nsString>&) [clone .part.245] () from /usr/lib64/firefox/libxul.so #2 0x00007fefe4059434 in gfxFontUtils::ReadCanonicalName(char const*, unsigned int, unsigned int, nsString&) () from /usr/lib64/firefox/libxul.so #3 0x00007fefe4059659 in gfxFontUtils::GetFullNameFromTable(hb_blob_t*, nsAString_internal&) () from /usr/lib64/firefox/libxul.so #4 0x00007fefe40599be in gfxFontUtils::GetFullNameFromSFNT(unsigned char const*, unsigned int, nsAString_internal&) () from /usr/lib64/firefox/libxul.so #5 0x00007fefe408e6f2 in gfxUserFontEntry::LoadPlatformFont(unsigned char const*, unsigned int&) () from /usr/lib64/firefox/libxul.so #6 0x00007fefe4092056 in gfxUserFontEntry::FontDataDownloadComplete(unsigned char const*, unsigned int, nsresult) () from /usr/lib64/firefox/libxul.so #7 0x00007fefe58b353c in nsFontFaceLoader::OnStreamComplete(nsIStreamLoader*, nsISupports*, nsresult, unsigned int, unsigned char const*) () from /usr/lib64/firefox/libxul.so #8 0x00007fefe32cc312 in nsStreamLoader::OnStopRequest(nsIRequest*, nsISupports*, nsresult) () from /usr/lib64/firefox/libxul.so #9 0x00007fefe3433bd2 in nsCORSListenerProxy::OnStopRequest(nsIRequest*, nsISupports*, nsresult) () from /usr/lib64/firefox/libxul.so #10 0x00007fefe346a47a in mozilla::net::nsHttpChannel::OnStopRequest(nsIRequest*, nsISupports*, nsresult) () from /usr/lib64/firefox/libxul.so #11 0x00007fefe32a6af4 in nsInputStreamPump::OnStateStop() () from /usr/lib64/firefox/libxul.so #12 0x00007fefe32a6f6f in nsInputStreamPump::OnInputStreamReady(nsIAsyncInputStream*) () from /usr/lib64/firefox/libxul.so #13 0x00007fefe31d453f in nsInputStreamReadyEvent::Run() () from /usr/lib64/firefox/libxul.so #14 0x00007fefe31ee06a in nsThread::ProcessNextEvent(bool, bool*) () from /usr/lib64/firefox/libxul.so #15 0x00007fefe32276aa in NS_ProcessNextEvent(nsIThread*, bool) () from /usr/lib64/firefox/libxul.so #16 0x00007fefe3599e6a in mozilla::ipc::MessagePump::Run(base::MessagePump::Delegate*) () from /usr/lib64/firefox/libxul.so #17 0x00007fefe3560f2c in MessageLoop::Run() () from /usr/lib64/firefox/libxul.so #18 0x00007fefe56b3b68 in nsBaseAppShell::Run() () from /usr/lib64/firefox/libxul.so #19 0x00007fefe62394de in nsAppStartup::Run() () from /usr/lib64/firefox/libxul.so #20 0x00007fefe629d8fa in XREMain::XRE_mainRun() () from /usr/lib64/firefox/libxul.so #21 0x00007fefe629e484 in XREMain::XRE_main(int, char**, nsXREAppData const*) () from /usr/lib64/firefox/libxul.so #22 0x00007fefe629e7f4 in XRE_main () from /usr/lib64/firefox/libxul.so #23 0x00000000004057d9 in do_main(int, char**, char**, nsIFile*) () #24 0x0000000000405060 in main () > What source are you compiling from, Gentoo ebuild, uses some patchset (didn't realize before), I hope it's not responsible. Going to file this bug on Gentoo bugtracker, letting them decide, it they caused it. Marking it as invalid for now, they (or you) can reopen it, if they (or you) believe this not to be their fault. > what does your mozconfig look like, Tried to check, what exactly you do mean, but first Google hit to https://developer.mozilla.org/en-US/docs/Mozilla/Developer_guide/Build_Instructions/Configuring_Build_Options made firefox crash again ... So, to be short: Gentoo default build. > and does this happen when using a mozilla.org build with crashreporting turned on? Hard to test when Firefox crashes upon accessing mozilla.org. Anyways: It seems, the problem only happens there (and developer.*) for now, beause many other other tabs got successfully restored on
Created attachment 447242 [details] emerge --info
(In reply to Bodo Thiesen from comment #1) > Created attachment 447242 [details] > emerge --info Please run revdep-rebuild, you most likely update a library that did not trigger an automatic rebuild. If this is not the case please post emerge --info Firefox as it will ensure I match your environment.
I have hint the same issue, but I think its an older issue. https://bugzilla.mozilla.org/show_bug.cgi?id=757366 -> It seems something similar was already seen 2012, but it still looks unfixed. My current "fix" is to diable @font-face via NoScript. No weird fonts == no crash. Is an backtrace from this crash interessting for you? I do not have enabled the full debug information, so its not much more than the backtraces in the linked moz bug, but I can post it, if you think it is relevant.
+================================================================= + Package Settings +================================================================= + +www-client/firefox-48.0.1::gentoo was built with the following: +USE="custom-cflags custom-optimization gmp-autoupdate hwaccel jemalloc3 jit skia -bindist -dbus -debug -gtk2 -hardened (-neon) -pgo -pulseaudio (-selinux) -startup-notification (-system-cairo) -system-harfbuzz -system-icu -system-jpeg -system-libevent -system-libvpx -system-sqlite -test -wifi" ABI_X86="64" L10N="-ach -af -an -ar -as -ast -az -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 -ga -gd -gl -gu -he -hi -hr -hsb -hu -hy -id -is -it -ja -kk -km -kn -ko -lt -lv -mai -mk -ml -mr -ms -nb -nl -nn -or -pa -pl -pt-BR -pt-PT -rm -ro -ru -si -sk -sl -son -sq -sr -sv -ta -te -th -tr -uk -uz -vi -xh -zh-CN -zh-TW" +CFLAGS="-march=amdfam10 -pipe" +CXXFLAGS="-march=amdfam10 -pipe" +LDFLAGS="-Wl,-O1 -Wl,--as-needed -Wl,-rpath=/usr/lib64/firefox,--enable-new-dtags" + I did build it with system-* use flags before, now I removed them, problem still persists. revdep-rebuild moroned about sci-libs/lapack-reference (and one application), did rebuild those, problem still persists. mozilla.org build doesn't crash btw.
I can confirm, that the bug is triggered by gcc 4.9. Recompiling with gcc 4.8.5 (with otherwise unchanged system) supresses the bug. From https://bugzilla.mozilla.org/show_bug.cgi?id=757366, -O3 may be needed too (I did compile with -O3), so I suggest preventing the build with gcc >=4.9 and -O3 until Mozilla fixed the issue. (I'm currently rebuilding with gcc 4.9.3 but -O2, reporting back once I checked for a crash again, after that I'll test again with gcc 5.3.0 -O2 and -O3).
gcc 4.9.3 -O2 = no crash
gcc 5.3.0 -O2 no crash
(In reply to Bodo Thiesen from comment #5) > I can confirm, that the bug is triggered by gcc 4.9. > Recompiling with gcc 4.8.5 (with otherwise unchanged system) supresses the > bug. > > From https://bugzilla.mozilla.org/show_bug.cgi?id=757366, -O3 may be needed > too (I did compile with -O3), so I suggest preventing the build with gcc > >=4.9 and -O3 until Mozilla fixed the issue. (I'm currently rebuilding with > gcc 4.9.3 but -O2, reporting back once I checked for a crash again, after > that I'll test again with gcc 5.3.0 -O2 and -O3). custom-optimization">Fine-tune custom compiler optimizations (-Os, -O0, -O1, -O2, -O3) custom-cflags - Build with user-specified CFLAGS (unsupported) Breakage is caused from your own use of experimental features that are not supported. Nothing for mozilla to do here.
(In reply to Jory A. Pratt from comment #8) > (In reply to Bodo Thiesen from comment #5) > > I suggest preventing the build with gcc > > >=4.9 and -O3 until Mozilla fixed the issue. > Breakage is caused from your own use of experimental features that are not > supported. Nothing for mozilla to do here. It's sad, that you just confirmed my prejudice of Gentoo developers to not care for their users yet again. But I guess, this attitude will help growing the Gentoo project, so keep going.
(In reply to Bodo Thiesen from comment #9) > (In reply to Jory A. Pratt from comment #8) > > (In reply to Bodo Thiesen from comment #5) > > > I suggest preventing the build with gcc > > > >=4.9 and -O3 until Mozilla fixed the issue. > > Breakage is caused from your own use of experimental features that are not > > supported. Nothing for mozilla to do here. > > It's sad, that you just confirmed my prejudice of Gentoo developers to not > care for their users yet again. But I guess, this attitude will help growing > the Gentoo project, so keep going. Dude, there's a reason why the optimization level you set is ignored unless you have USE="custom-optimization" set, and that is because upstream's codebase is very optimization-level sensitive. We provide that flag so you can mess about if you so choose, but if you do so you get to pick up the pieces. If you want things to just work, turn off that flag. Simple. :)
This justifications of your practices would be really funny, if they wouldn't affect users. custom-cflags (which is officially unsupported) didn't cause the problem, custom-optimization (which doesn't give a hint about being unsupported) did (because of -O3). In mozcoreconf-v4.eclass you check for ppc & >=sys-libs/glibc-2.8 and force -O1 there, because »more than -O1 segfaults on ppc with glibc-2.8«. But you refuse to add another exception for >=gcc-4.9 and -O3. Now, we can discuss this the next three years, but from my experience, it's worthless, so, as I told already: Keep going if you think, justifications of your errors help the project. Oh, and before you repeat, that custom-optimization is unsupported, show me where it says so.
Agreed -- our documentation on this is lacking. Fixed now: commit b0f276d40699578dc9fbcf2dce3f65e291530d77 Author: Ian Stakenvicius <axs@gentoo.org> Date: Mon Sep 26 10:56:57 2016 -0400 mozilla packages: clarified description of USE=custom-optimization diff --git a/www-client/firefox/metadata.xml b/www-client/firefox/metadata.xml index fbdfd67..aee28e8 100644 --- a/www-client/firefox/metadata.xml +++ b/www-client/firefox/metadata.xml @@ -8,8 +8,8 @@ <use> <flag name="bindist">Disable official Firefox branding (icons, name) which are not binary-redistributable according to upstream.</flag> - <flag name="custom-optimization">Fine-tune custom compiler - optimizations (-Os, -O0, -O1, -O2, -O3)</flag> + <flag name="custom-optimization">Build with user-specified compiler optimizations + (-Os, -O0, -O1, -O2, -O3) from CFLAGS (unsupported)</flag> <flag name="gtk2">Use the cairo-gtk2 rendering engine</flag> <flag name="gmp-autoupdate">Allow Gecko Media Plugins (binary blobs) to be automatically downloaded and kept up-to-date in user profiles</flag>
@Ian: Better than nothing, but I generally dislike the Idea of documenting bugs :P Anyways: Mozilla fixed the issue, maybe you want to backport the fix. https://bugzilla.mozilla.org/show_bug.cgi?id=757366#c9 (and following comments, #c12 contains the link to the actual diff for version 52)
(In reply to Bodo Thiesen from comment #13) > @Ian: Better than nothing, but I generally dislike the Idea of documenting > bugs :P > > Anyways: Mozilla fixed the issue, maybe you want to backport the fix. > > https://bugzilla.mozilla.org/show_bug.cgi?id=757366#c9 (and following > comments, #c12 contains the link to the actual diff for version 52) No, but thank you for the suggestion :) Comment #9 though is precisely why gentoo isn't allowing CFLAGS-specified optimization by default, and hiding it behind USE="custom-optimization" instead.
