Description of problem: Firefox-50.0-1 segfaults when viewing stock market charts. Some examples below. Version-Release number of selected component (if applicable): firefox-50.0-1 How reproducible: Always. Clean install, safe mode, another machine - whatever, does not help. Steps to Reproduce: 1. Go to for example https://www.tradingview.com/chart/?symbol=NYSE%3ASAN http://www.investing.com/equities/tobii-ab-chart and try to use the fullscreen technical chart. 2. 3. Actual results: Firefox segfaults either immediately or within the first 10-30 sec. Expected results: Firefox remains stable and works flawlessly. Additional info: Those pages (which are only a few examples, there are more which trigger the segfault) worked flawlessly over a long time. Firefox < 50 is fine.
Here's the last lines of a strace output when segfaulting: [....] recvmsg(48, {msg_namelen=0}, 0) = -1 EAGAIN (Resource temporarily unavailable) recvmsg(48, {msg_namelen=0}, 0) = -1 EAGAIN (Resource temporarily unavailable) poll([{fd=48, events=POLLIN|POLLOUT}], 1, -1) = 1 ([{fd=48, revents=POLLOUT}]) writev(48, [{iov_base="<\0\2\0\0\0\240\3+\1\1\0", iov_len=12}, {iov_base=NULL, iov_len=0}, {iov_base="", iov_len=0}], 3) = 12 poll([{fd=48, events=POLLIN}], 1, -1) = 1 ([{fd=48, revents=POLLIN}]) recvmsg(48, {msg_name=NULL, msg_namelen=0, msg_iov=[{iov_base="\1\2\f\0\0\0\0\0 \0\240\2\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0", iov_len=4096}], msg_iovlen=1, msg_controllen=0, msg_flags=0}, 0) = 32 recvmsg(48, {msg_namelen=0}, 0) = -1 EAGAIN (Resource temporarily unavailable) recvmsg(48, {msg_namelen=0}, 0) = -1 EAGAIN (Resource temporarily unavailable) shutdown(48, SHUT_RDWR) = 0 close(48) = 0 write(2, "\7", 1) = 1 write(2, "[Parent 9575] ###!!! ABORT: X_Sh"..., 210[Parent 9575] ###!!! ABORT: X_ShmAttach: BadAccess (attempt to access private resource denied); 12 requests ago: file /builddir/build/BUILD/firefox-50.0/firefox-50.0/toolkit/xre/nsX11ErrorHandler.cpp, line 147 ) = 210 write(2, "[Parent 9575] ###!!! ABORT: X_Sh"..., 209[Parent 9575] ###!!! ABORT: X_ShmAttach: BadAccess (attempt to access private resource denied); 12 requests ago: file /builddir/build/BUILD/firefox-50.0/firefox-50.0/toolkit/xre/nsX11ErrorHandler.cpp, line 147) = 209 write(2, "\n", 1 ) = 1 --- SIGSEGV {si_signo=SIGSEGV, si_code=SEGV_MAPERR, si_addr=NULL} --- unlink("/home/htd/.mozilla/firefox/vwakpl06.default/lock") = 0 close(7) = 0 rt_sigaction(SIGSEGV, {SIG_DFL, [], SA_RESTORER, 0x7fee6cc55c30}, NULL, 8) = 0 rt_sigprocmask(SIG_UNBLOCK, [SEGV], NULL, 8) = 0 tgkill(9575, 9575, SIGSEGV) = 0 --- SIGSEGV {si_signo=SIGSEGV, si_code=SI_TKILL, si_pid=9575, si_uid=1000} --- [NPAPI 9706] ###!!! ABORT: Aborting on channel error.: file /builddir/build/BUILD/firefox-50.0/firefox-50.0/ipc/glue/MessageChannel.cpp, line 2056 [NPAPI 9706] ###!!! ABORT: Aborting on channel error.: file /builddir/build/BUILD/firefox-50.0/firefox-50.0/ipc/glue/MessageChannel.cpp, line 2056 ###!!! [Child][MessageChannel] Error: (msgtype=0x420003,name=PCompositable::Msg_Destroy) Channel error: cannot send/recv [Child 9666] ###!!! ABORT: Aborting on channel error.: file /builddir/build/BUILD/firefox-50.0/firefox-50.0/ipc/glue/MessageChannel.cpp, line 2056 [Child 9666] ###!!! ABORT: Aborting on channel error.: file /builddir/build/BUILD/firefox-50.0/firefox-50.0/ipc/glue/MessageChannel.cpp, line 2056 ###!!! [Child][MessageChannel] Error: (msgtype=0x1060003,name=PTexture::Msg_Destroy) Channel error: cannot send/recv +++ killed by SIGSEGV (core dumped) +++ Segmentation fault (core dumped) [htd@chiara ~]$
Created attachment 1222186 [details] Output of strace
Yes, I can see that. Can you please try to run firefox as: $GDK_SYNCHRONIZE=1 firefox
Hi Martin, played with GDK_SYNCHRONIZE=1 set for about 5 minutes, and the segfault seems to be gone.
[htd@kiera ~]$ rpm -qa | grep -i "firefox" firefox-50.0-1.fc24.x86_64 This is plain firefox started from the console when viewing some random technical stock market chart on investing.com. The crash occurs within seconds: [htd@kiera ~]$ firefox [7770] ###!!! ABORT: X_ShmAttach: BadAccess (attempt to access private resource denied); 16 requests ago: file /builddir/build/BUILD/firefox-50.0/firefox-50.0/toolkit/xre/nsX11ErrorHandler.cpp, line 147 [7770] ###!!! ABORT: X_ShmAttach: BadAccess (attempt to access private resource denied); 16 requests ago: file /builddir/build/BUILD/firefox-50.0/firefox-50.0/toolkit/xre/nsX11ErrorHandler.cpp, line 147 Segmentation fault (core dumped) After playing som more, I now can definitely approve that there is no more segfault using firefox-50.0-1.fc24.x86_64 when GDK_SYNCHRONIZE=1 is set.
Thanks, that means there's a bug in rendering via X window. Unfortunately GDK_SYNCHRONIZE=1 should provide more accurate debug info about the issue because all X calls are flushed immediately - but it actually fixes that because all X calls are synced.
btw. can you please test stock FF from mozilla.com ? You may also test a latest nightly (unstable developer version) from https://archive.mozilla.org/pub/firefox/nightly/latest-mozilla-central/, the binary is: https://archive.mozilla.org/pub/firefox/nightly/latest-mozilla-central/firefox-53.0a1.en-US.linux-x86_64.tar.bz2
I have now tested nightly "Firefox-53.0a1 (2016-11-22) (64-bit)", and I have not encountered any crash within roughly 5 minutes of testing. Usually, the crash occurs either immediately or within a few seconds. I think this nightly does not have the bug. Will test stock Firefox tomorrow and report back here.
Bog standard firefox from mozilla.org also works properly, no crash within ~ 10 min. of stock analysis. Seems to be a Fedora specific problem.
Thanks. I wonder which change should do that, I'm not aware of any such patch we have in Fedora.
Maybe it's not a patch, but something in the environment (X, GTK, whatever..), a compile time option/parameter... I don't know. What I know fur sure is that I can reliably reproduce the crash on three different machines running F24. Will do a fresh F24 install on a fourth machine in the evening and report back. I can also recompile firefox with the original mozilla sourcecode if you think that helps.
Thanks, I think I have all the info I need from this POV. I tested plain FF50 build without any patch and still crashes for me in Fedora 25. I also tested nightly built on Fedora 25 and it does not crash...looks like the fix is in nightly already or does not happens on nightly due to different config (enabled e10s, GL layers or so).
I managed to get crash with stock Firefox from mozilla.com but on my default profile. When tested on a fresh one, it does not crash. Looks like it's caused by some extension. Can you please test Fedora Firefox on fresh profile ($firefox -ProfileManager) or on safe mode ($firefox -safe-mode)?
I already tried that, without success (see post #1). I now created a new user, and recent Fedora 24 Firefox 50 crashed within a second when viewing one of those stock charts. No extensions or add-ons.
This may be related: https://bugzilla.mozilla.org/show_bug.cgi?id=1271100
Thanks, Martin, for your effort! I think you're right. The link given in answer #32 in the thread you mention triggers the same crash of Firefox 50, according to strace. The same thread also shows that updating to FF50 triggered the same bug in Linux Mint, so there is definitely going on something outside of Fedora. Please let me know if (and how) I can help.
According to the suggestions made in comment #42 in the thread from comment #15 above, I applied the following two patches to latest Fedora 25 cairo: 1. author Uli Schlachter <psychon> 2015-11-06 19:50:47 (GMT) committer Uli Schlachter <psychon> 2015-11-06 19:50:47 (GMT) commit bf41cc397f460978eaf0aa35bc7341cefc9817b5 (patch) tree 9f5d3544808f9ce58ef844226989a3deacd10f71 parent fc689d7d351cca1f1b11cef9137fa2c6eec0ee25 (diff) Fix cairo-xlib-xcb compilation 2. author Marc-André Lureau <marcandre.lureau> 2015-11-06 17:13:05 (GMT) committer Uli Schlachter <psychon> 2015-11-06 20:00:48 (GMT) commit 98d01cd119eaa7d50cf0ec6c6cc32ee170397ad5 (patch) tree 43e85223fa644bb598afd035a96f8c82029d07a3 parent bf41cc397f460978eaf0aa35bc7341cefc9817b5 (diff) xlib: fix mixing xcb & xlib calls No more crashes so far with F25 FF50. Will test some more and report back.
After some more testing (about 1 hour continuously) I now can confirm that the patches in comment #17 have fixed it. No more crashes with FF50 on Fedora 25. Thus, I think this is mainly a cairo problem, but I'm not familiar with either the firefox or cairo sourcecode.
Yes, patching cairo would help here. Moving to Cairo component.
Benjamin, look at https://bugzilla.mozilla.org/show_bug.cgi?id=1271100#c45 for details. Would be great to have this workaround in system cairo if possible.
This message is a reminder that Fedora 24 is nearing its end of life. Approximately 2 (two) weeks from now Fedora will stop maintaining and issuing updates for Fedora 24. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as EOL if it remains open with a Fedora 'version' of '24'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora 24 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged change the 'version' to a later Fedora version prior this bug is closed as described in the policy above. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete.
Fedora 24 changed to end-of-life (EOL) status on 2017-08-08. Fedora 24 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. If you are unable to reopen this bug, please file a new report against the current release. If you experience problems, please add a comment to this bug. Thank you for reporting this bug and we are sorry it could not be fixed.