Created attachment 415846 [details] emerge-info.log this is from dmesg, I will try to provide a more usefull backtrace later on. [ 669.188919] firefox[2150]: segfault at 44d00000d9b ip 00007f3c82f02740 sp 00007ffce8295658 error 4 in libX11-xcb.so.1.0.0[7f3c82f02000+200000]
Hello, from where did you take firefox 42 beta 9? I cannot find it in portage.
the ebuild is from the mozilla overlay.
Would it be possible to provide more information? Do you observe segfaults on other software as well (is it really a Firefox-Musl specific problem)? Please provide the output of emerge -pvq firefox and preferably a backtrace of a crash. Maybe even a list of plugins used.
Is this the first Firefox you see segfaults or it happened on a previous Firefox release on musl?
(In reply to tt_1 from comment #2) > the ebuild is from the mozilla overlay. 42.0-r1 is in the mozilla overlay please test it and report your findings.
Created attachment 416474 [details] firefox backtrace I recompiled firefox with -gddb cflags. It segfault's right away when run from within gdb, and randomly if not using gdb. Is the backtrace helpful? Actually it is 42.0-r99 from the musl overlay, don't know for which reason I should use your -r1? And actually 38.x is working stable, but gives a similar segfault when run from within gdb - please tell me if you are interested into that backtrace as well.
(In reply to tt_1 from comment #6) > Created attachment 416474 [details] > firefox backtrace > > I recompiled firefox with -gddb cflags. It segfault's right away when run > from within gdb, and randomly if not using gdb. Is the backtrace helpful? > > Actually it is 42.0-r99 from the musl overlay, don't know for which reason I > should use your -r1? And actually 38.x is working stable, but gives a > similar segfault when run from within gdb - please tell me if you are > interested into that backtrace as well. You were requested to use the --r1 from mozilla overlay due to fact it is being made to officially support musl. I do not have commit access to musl overlay no do I intend to get it.
firefox-42.0-r99 is not even in the musl overlay. So nobody knows what patches tt_1 might be using. firefox-42.0-r1 from mozilla overlay obviously won't build with musl. @tt_1: The backtrace does not show any segfault. (Try using "continue".)
(In reply to Felix Janda from comment #8) > firefox-42.0-r99 is not even in the musl overlay. So nobody knows what > patches tt_1 might be using. > > firefox-42.0-r1 from mozilla overlay obviously won't build with musl. > > @tt_1: The backtrace does not show any segfault. (Try using "continue".) If you are gonna make such an assumption show a bug report that actually shows it wont build. To make a claim without the proof is very disrespectful to those of us working to improve the users experience.
Sorry, for my rudeness. I did not know that any of the musl patches landed in the mozilla-patches. Thanks! So it might build. Is there any bug about this? Will the mozilla team help with upstreaming them? Sorry for being off-topic.
(In reply to Felix Janda from comment #10) > Sorry, for my rudeness. I did not know that any of the musl patches > landed in the mozilla-patches. Thanks! So it might build. > > Is there any bug about this? Will the mozilla team help with > upstreaming them? Sorry for being off-topic. Not a problem. Yes I will work directly with upstream to get them landed asap.
Hmm, the mozilla patches look directly copied from alpine. They won't be enough since alpine also adds a "stab.h" header, which musl is missing. https://bugs.chromium.org/p/google-breakpad/issues/detail?id=631 is related.
(In reply to Felix Janda from comment #12) > Hmm, the mozilla patches look directly copied from alpine. They won't > be enough since alpine also adds a "stab.h" header, which musl is missing. > https://bugs.chromium.org/p/google-breakpad/issues/detail?id=631 is related. breakpad is only built on debug builds.
Created attachment 416510 [details, diff] firefox-42.0 libavutils patch actually I forgot that I hadn't yet uploaded the 42.0-r99 ebuild + patches to bug 531846 , so sorry for the confusion. anyway, from 41.0.2 to 42.0 there are three patches which had to be updated in terms of that upstream changed something in the patterns of the files within the source code tree. also, there is a new bug which lead to a compile failure, the patch fixing this is also used by alpine and simply deletes the reference to sys/sysctl.h in media/libav/libavutil/cpu.c - I have added the patch as attachement. @ Jory - please have a look at the libav-patch and eventually inform upstream about it.
Created attachment 416512 [details] build log from 42.0_b9 build without the libavutils.patch - it is actually the same build failure as it would be with 42.0
Actually 42.0 is the first firefox I do see segfault when being built with musl. 38.4.0 is stable in my opinion, but I haven't tested it exhaustingly. I will try to provide some more helpfull logs later on.
Created attachment 416524 [details] enhanced log so I tried to get a more usefull output with continue after bt all lines with > in the beginning are comments made by me. is there a way to get a more verbose comment at line 44 - 55 ? I added -gddb cflags to firefox, musl, nss, nspr, libX11.
someone show me their useflags, please also include the flags you built cairo with if your using system-cairo flag.
these are my useflags [ebuild R ~] www-client/firefox-42.0-r99::musl USE="dbus gstreamer jemalloc3 jit minimal system-cairo system-icu system-jpeg system-libvpx system-sqlite -bindist -custom-cflags -custom-optimization -debug -egl -gmp-autoupdate -gstreamer-0 -gtk3 (-hardened) (-neon) (-pgo) -pulseaudio (-selinux) -startup-notification {-test} -wifi" LINGUAS="de -af -ar -as -ast -be -bg -bn_BD -bn_IN -br -bs -ca -cs -cy -da -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" this is from genlop about cairo, showing the cflags. is it helpfull? * x11-libs/cairo-1.14.2 Install date: Sat Oct 31 22:23:01 2015 USE="X opengl -aqua -debug -directfb -gles2 -+glib -static-libs -+svg -valgrind -xcb -xlib-xcb" CFLAGS="-march=core2 -O2 -pipe -fomit-frame-pointer" CXXFLAGS="-march=core2 -O2 -pipe -fomit-frame-pointer" LDFLAGS="-Wl,-O1 -Wl,--as-needed"
(In reply to tt_1 from comment #19) > these are my useflags > > [ebuild R ~] www-client/firefox-42.0-r99::musl USE="dbus gstreamer > jemalloc3 jit minimal system-cairo system-icu system-jpeg system-libvpx > system-sqlite -bindist -custom-cflags -custom-optimization -debug -egl > -gmp-autoupdate -gstreamer-0 -gtk3 (-hardened) (-neon) (-pgo) -pulseaudio > (-selinux) -startup-notification {-test} -wifi" LINGUAS="de -af -ar -as -ast > -be -bg -bn_BD -bn_IN -br -bs -ca -cs -cy -da -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" > > > this is from genlop about cairo, showing the cflags. is it helpfull? > > * x11-libs/cairo-1.14.2 > Install date: Sat Oct 31 22:23:01 2015 > USE="X opengl -aqua -debug -directfb -gles2 -+glib -static-libs -+svg > -valgrind -xcb -xlib-xcb" > CFLAGS="-march=core2 -O2 -pipe -fomit-frame-pointer" > CXXFLAGS="-march=core2 -O2 -pipe -fomit-frame-pointer" LDFLAGS="-Wl,-O1 > -Wl,--as-needed" xcb has been default enabled via the eclass for 42.0 for very good reasons. This is liable to resolve your crash.
Created attachment 416652 [details] firefox backtrace I added the xcb useflag for cairo. do I have to recompile firefox afterwards? I haven't yet and so the new backtrace is a result of the changed use flag.
(In reply to tt_1 from comment #21) > Created attachment 416652 [details] > firefox backtrace > > I added the xcb useflag for cairo. do I have to recompile firefox > afterwards? > > I haven't yet and so the new backtrace is a result of the changed use flag. this has been fixed in mozilla overlay already, Felix is running 42.0-r2 from the overlay successfully I believe.
I will test the -r2 soon on amd64.
I used the in tree -r2 ebuild and it is not compiling on amd64. Please reopen #531846
There is also #559784 and #545502 being a blocker as they are not resolved.
I'm running 42.0-r2 from overlay successfully. However I have only tested arm.
closing