|Summary:||www/firefox: update to 60.0|
|Product:||Ports & Packages||Reporter:||Jan Beich <jbeich>|
|Component:||Individual Port(s)||Assignee:||freebsd-gecko mailing list <gecko>|
|Severity:||Affects Only Me||CC:||cpm, debdrup, gecko, grahamperrin, greg, jakub_lach, jrm, lwhsu|
|Bug Depends on:||223425, 225627|
Description Jan Beich 2018-03-09 15:04:41 UTC
Created attachment 191341 [details] beta2 (devedition) Due to chronic lack of time this may be the last release to support WebRTC. For 60 gyp->gn conversion was reverted (see files/patch-a-gyp-webrtc) but after WebRTC is updated only --disable-webrtc will work.  https://bugzilla.mozilla.org/show_bug.cgi?id=1437670  https://bugzilla.mozilla.org/show_bug.cgi?id=1376873
Comment 1 Carlos J. Puga Medina 2018-03-09 21:44:15 UTC
In Chromium, it has been the other way around; now WebRTC is required by default to compile Chromium. Unfortunately, WebRTC is not fully supported on FreeBSD.
Comment 4 Tobias Kortkamp 2018-03-16 17:25:49 UTC
Created attachment 191556 [details] bsd.gecko.mk-sndio.diff Hi, 60.0b4 fails to patch with SNDIO=on because webrtc has moved a little bit in the tree. Patching webrtc doesn't seem to be necessary anymore so guarding it for older Gecko versions (like we did with the cubeb tests a while ago) should be enough to workaround this. I built Waterfox and Firefox 60.0b4 with the attached patch and everything seems to work ok as before. Can you include it in the update?
Comment 5 Tobias Kortkamp 2018-03-17 07:43:25 UTC
Comment on attachment 191556 [details] bsd.gecko.mk-sndio.diff The patch is needed for a Pale Moon update as well when building with SNDIO=on since they completely removed WebRTC code in 27.8.0. Ok to land it now?
Comment 6 Jan Beich 2018-03-18 23:07:38 UTC
Comment on attachment 191556 [details] bsd.gecko.mk-sndio.diff Looks OK. "if...fi" block can have more than one command or none at all (e.g., "if true; false; then else fi") terminated by either newline or semicolon. By terminating a command on the same line as "fi" you're making it harder to append another command within the conditionals.
Comment 7 commit-hook 2018-03-19 05:47:04 UTC
A commit references this bug: Author: tobik Date: Mon Mar 19 05:46:03 UTC 2018 New revision: 464981 URL: https://svnweb.freebsd.org/changeset/ports/464981 Log: Fix post-patch-SNDIO-on in preparation of updates to www/firefox 60.0 and to www/palemoon 27.8.1 Some patches no longer apply to them. WebRTC has moved paths in Firefox 60.0 and no longer needs to be patched. Pale Moon removed WebRTC completely in 27.8.0. PR: 226476 Approved by: gecko (jbeich) Changes: head/Mk/bsd.gecko.mk
Comment 8 Jan Beich 2018-03-20 01:01:42 UTC
Created attachment 191654 [details] beta5 WebRTC is back on track with Landry's help. Unfortunately, I haven't found time to rebase libv4l patch.
Comment 9 Tobias Kortkamp 2018-03-22 16:02:10 UTC
(In reply to Jan Beich from comment #8) beta5 builds fine and also mostly runs ok, however when I try to print something it takes forever for the print preview window to actually show up and the UI completely freezes up. Hmm, this also happens with Firefox 59.0.1,1 with default options, so I guess it's nothing new.
Comment 10 Tobias Kortkamp 2018-03-22 16:31:36 UTC
(In reply to Tobias Kortkamp from comment #9) It happened because I had the sysctl net.inet.tcp.blackhole=2 set. Setting it back to 0 fixes this.
Comment 11 Jan Beich 2018-03-23 00:08:18 UTC
Created attachment 191746 [details] beta6 (crashes on i386) https://hg.mozilla.org/releases/mozilla-beta/pushloghtml?startdate=2018-03-19&enddate=2018-03-23 And https://bugzilla.mozilla.org/show_bug.cgi?id=1436911 as a "pkg upgrade" crashfix i386 issue: https://bugzilla.mozilla.org/show_bug.cgi?id=1448189
Comment 12 Jan Beich 2018-03-24 10:47:37 UTC
Created attachment 191780 [details] beta6 (rebased after r465446)
Comment 13 Jan Beich 2018-03-26 23:57:31 UTC
Comment 14 Jan Beich 2018-03-28 12:33:19 UTC
Can someone build the binary package(s) for beta7 or (tonight) for beta8? A user contacted me privately offering to help testing Firefox 60 but lacks powerful enough hardware to build the port. Bug 222225 comment 17 describes why I can't.
Comment 15 Greg V 2018-03-28 20:58:37 UTC
(In reply to Jan Beich from comment #14) Package for stable or current?
Comment 16 D. Ebdrup 2018-03-29 08:03:20 UTC
Ah, my apologies. I somehow completely missed finding this bug when searching for it. I'm on 11.1-RELEASE, so I imagine -STABLE should do it?
Comment 17 Jan Beich 2018-03-29 08:19:25 UTC
Comment 18 D. Ebdrup 2018-03-29 09:18:52 UTC
Should've probably just included uname -a from the start: FreeBSD nerd-thinkpad.local 11.1-RELEASE-p8 FreeBSD 11.1-RELEASE-p8 #0: Tue Mar 13 17:07:05 UTC 2018 email@example.com:/usr/obj/usr/src/sys/GENERIC amd64
Comment 19 Jan Beich 2018-03-30 03:22:55 UTC
Created attachment 191963 [details] beta8 (rebased against ports r465943) https://hg.mozilla.org/releases/mozilla-beta/pushloghtml?startdate=2018-03-27&enddate=2018-03-30
Comment 20 Jan Beich 2018-04-03 02:41:47 UTC
Comment 21 Jan Beich 2018-04-05 00:57:41 UTC
Created attachment 192238 [details] beta10 (rebased after ports r466432) https://hg.mozilla.org/releases/mozilla-beta/pushloghtml?startdate=2018-04-03&enddate=2018-04-05
Comment 22 D. Ebdrup 2018-04-06 12:16:55 UTC
So, there's no chance of having someone build it? Although I see that v4l is getting dropped for lack of time, so webcam support is gonna break anyhow, it seems.. Wish I had the talent or money to do something about that, but I don't.
Comment 23 Jan Beich 2018-04-06 12:39:13 UTC
Not v4l but libv4l. Only useful if a webcam doesn't support v4l2 or one of WebRTC video formats. Contributed by someone who had JPEG-only camera but, looking at the code, libv4l should no longer be necessary.  https://searchfox.org/mozilla-central/rev/d0413b711da4/media/webrtc/trunk/webrtc/modules/video_capture/linux/video_capture_linux.cc#222-230  https://chromium.googlesource.com/external/webrtc/+/6b6eb44cca%5E!/
Comment 24 Joseph Mingrone 2018-04-08 11:44:08 UTC
b10 builds successfully here with the options below: http://pkg.awarnach.mathstat.dal.ca/data/11amd64-default/2018-04-08_08h09m26s/logs/firefox-60.0.b10,1.log % poudriere options -j 11amd64 -sn www/firefox [00:00:00] Appending to make.conf: /usr/local/etc/poudriere.d/make.conf ===> The following configuration options are available for firefox-60.0.b10,1: CANBERRA=off: Sound theme alerts DBUS=off: D-Bus IPC system support DEBUG=off: Build with debugging support DTRACE=on: Build with DTrace probes FFMPEG=on: FFmpeg support (WMA, AIFF, AC3, APE...) GCONF=off: GConf configuration backend support INTEGER_SAMPLES=off: Integer audio sample format LIBPROXY=off: Proxy support via libproxy OPTIMIZED_CFLAGS=on: Use extra compiler optimizations PROFILE=off: Build with profiling support TEST=off: Build and/or run tests ====> Options available for the multi AUDIO: you have to choose at least one of them ALSA=off: ALSA audio architecture support JACK=off: JACK audio server support PULSEAUDIO=off: PulseAudio sound server support SNDIO=on: Sndio audio support I will also test with default options and report back.
Comment 25 Joseph Mingrone 2018-04-08 12:48:36 UTC
Looks good with default options: http://pkg.awarnach.mathstat.dal.ca/data/11amd64-default/2018-04-08_08h44m27s/logs/firefox-60.0.b10,1.log
Comment 26 D. Ebdrup 2018-04-09 20:46:10 UTC
Since my webcam feed isn't showing up in Firefox 60 beta10 with default options, despite the fact that it works in Firefox 58 (from the official packages), I decided to try enabling debug options. However, even with MAKE_UNSAFE_JOBS=yes, I get the error shown on  while running make package with the debug option enabled on a system with FreeBSD 11.1-STABLE r330643 according to uname -a.  http://termbin.com/43yi
Comment 27 Jan Beich 2018-04-09 22:13:26 UTC
I neither own a microphone or web camera nor smart enough to emulate those in order to help investigate WebRTC issues. (In reply to D. Ebdrup from comment #26) > my webcam feed isn't showing up Maybe check IPC limits. For one, OpenBSD has smaller kern.shminfo.shmall default than kern.ipc.shmall on FreeBSD which breaks screen capture. > it works in Firefox 58 DEBUG build or logging won't help much unless you know what to look for. mozregression isn't usable on Tier3 platforms like FreeBSD (no upstream builds, flo@'s buildbot is down for months), so try bisecting source instead. Here's how to build Firefox outside of ports: $ pkg install python27 binutils $ hash git 2>/dev/null || pkg install mercurial $ hg clone https://hg.mozilla.org/mozilla-unified firefox || git clone https://github.com/mozilla/gecko-dev firefox $ cd firefox $ hg update release || git checkout origin/release $ echo "export COMPILER_PATH=/usr/local/bin" >>.mozconfig $ echo "ac_add_options --disable-debug-symbols" >>.mozconfig $ ./mach bootstrap # select Firefox for Desktop $ ./mach build $ ./mach run https://mozilla.github.io/webrtc-landing/  https://wiki.mozilla.org/Media/WebRTC/Logging > ../../build/unix/gold/ld: error: /usr/ports/www/firefox/work/.build/toolkit/library/../../js/src/js-dtrace.o: unexpected reloc 8 in object file > /usr/ports/www/firefox/work/.build/toolkit/library/../../js/src/js-dtrace.o:/usr/src/cddl/lib/drti/../../../cddl/contrib/opensolaris/lib/libdtrace/common/drti.c:__SUNW_dof: > error: unexpected reloc 8 in object file > c++: error: linker command failed with exit code 1 (use -v to see invocation) Disable DTRACE option and try again.
Comment 28 Jan Beich 2018-04-10 00:21:44 UTC
Created attachment 192374 [details] beta11 (rebased after ports r466648) https://hg.mozilla.org/releases/mozilla-beta/pushloghtml?startdate=2018-04-05&enddate=2018-04-10
Comment 29 D. Ebdrup 2018-04-10 12:12:44 UTC
(In reply to Jan Beich from comment #27) >OpenBSD But I'm using FreeBSD, so I don't see how that's relevant. Still, I've upped kern.ipc.shmall to 262k instead of the 131k it was at - so whatever limits there may be shouldn't be a problem. >Logging I'll try messing around with it anyhow - with pkg, it's remarkably easy to switch between the working and non-working version of Firefox, so I should be able to tell if it reports anything different, and possibly find out what that means. >Disable DTRACE option The thing is, I only get the dtrace errors if the DEBUG option is turned on. The first package that I built, and that I'm using to test with, is built with default options and didn't get any errors. Long of the short of it is - Don't feel you have to delay the port on my account, though - if I need webrtc, I'll install the working version temporarily, no reason to have that delay a new version of the port going out. If I find a real bug in FreeBSDs port, or better yet a fix, I'll file a separate report.
Comment 30 Jan Beich 2018-04-13 13:01:18 UTC
Comment 31 Jan Beich 2018-04-17 01:37:59 UTC
Created attachment 192576 [details] beta13 (rebased after ports r467551) https://hg.mozilla.org/releases/mozilla-beta/pushloghtml?startdate=2018-04-13&enddate=2018-04-17
Comment 32 Li-Wen Hsu 2018-04-17 08:53:15 UTC
beta13 works for me (12.0-CURRENT r332357). I tested some demoes on https://webrtc.github.io/samples/ and look good to me. Sadly, Google Handouts still doesn't work.
Comment 33 Jan Beich 2018-04-20 15:19:14 UTC
Comment 34 Jan Beich 2018-04-24 18:28:59 UTC
Comment on attachment 192684 [details] beta14 Time to move the patch to Phabricator. Bugzilla support for interdiffs is poor and it doesn't allow patches larger than 1 Mb. Firefox 60 enables WebAuthn by default with Google Accounts support. Greg V implemented FreeBSD support, so I've integrated it into the patch. https://firstname.lastname@example.org/msg24759.html https://github.com/jcjones/u2f-hid-rs/pull/62 Patch: https://reviews.freebsd.org/D15186?download=true Changes (since beta14): https://hg.mozilla.org/releases/mozilla-beta/pushloghtml?startdate=2018-04-20&enddate=2018-04-24
Comment 35 commit-hook 2018-05-01 00:52:14 UTC
A commit references this bug: Author: jbeich Date: Tue May 1 00:51:38 UTC 2018 New revision: 468751 URL: https://svnweb.freebsd.org/changeset/ports/468751 Log: www/firefox: update to 60.0 - Add U2F support, required by Web Authentication  - Drop libv4l support to reduce maintenance Changes: https://www.mozilla.org/firefox/60.0/releasenotes/ PR: 226476 Tested by: tobik, jrm, D. Ebdrup, lwhsu Submitted by: Greg V  Security: 5aefc41e-d304-4ec8-8c82-824f84f08244 MFH: 2018Q2 Differential Revision: https://reviews.freebsd.org/D15186 Changes: head/Mk/Uses/gecko.mk head/Mk/bsd.gecko.mk head/www/firefox/Makefile head/www/firefox/distinfo head/www/firefox/files/patch-bug1021761 head/www/firefox/files/patch-bug1433747 head/www/firefox/files/patch-bug1438678 head/www/firefox/files/patch-bug1444083 head/www/firefox/files/patch-bug1444798 head/www/firefox/files/patch-bug1447925 head/www/firefox/files/patch-bug1452041 head/www/firefox/files/patch-bug826985 head/www/firefox/files/patch-u2f-hid-rs62 head/www/firefox/files/patch-z-bug1436911 head/www/firefox/files/patch-z-bug517422 head/www/firefox/pkg-message head/www/firefox-i18n/Makefile head/www/firefox-i18n/Makefile.lang head/www/firefox-i18n/Makefile.option head/www/firefox-i18n/distinfo
Comment 36 Jan Beich 2018-05-01 01:05:31 UTC
60 rollout has started, ahead of upstream because our QA is different. www/firefox-i18n is still at beta16 due to a hiccup on Mozilla infra but it should work fine with rc1.  https://treeherder.mozilla.org/#/jobs?repo=mozilla-release&revision=9ef500ce24aa
Comment 37 jakub_lach 2018-05-01 14:38:48 UTC
I've lost l18n in xterm/firefox after upgrade to firefox 60. I wonder what has happened in that timeframe?
Comment 38 jakub_lach 2018-05-01 15:07:21 UTC
(In reply to jakub_lach from comment #37) ^ that was recent xkbcomp update
Comment 39 commit-hook 2018-05-03 20:42:06 UTC
A commit references this bug: Author: jbeich Date: Thu May 3 20:41:54 UTC 2018 New revision: 468985 URL: https://svnweb.freebsd.org/changeset/ports/468985 Log: www/firefox: switch to rc2 Changes: https://hg.mozilla.org/releases/mozilla-release/pushloghtml?startdate=2018-05-01&enddate=2018-05-04 PR: 226476 Changes: head/www/firefox/Makefile head/www/firefox/distinfo head/www/firefox-i18n/Makefile head/www/firefox-i18n/distinfo
Comment 40 Graham Perrin 2018-05-05 13:33:22 UTC
60.0,1 looking good to me, thanks.
Comment 41 jakub_lach 2018-05-05 14:07:31 UTC
I know that's not much, but since Firefox 60 introduction to www/firefox, it was nothing but multiple coredumps daily, something I have not seen for a very long time.
Comment 42 jakub_lach 2018-05-05 14:10:52 UTC
May 5 16:05:18 Thinkpad kernel: pid 750 (firefox), uid 1001: exited on signal 11 (core dumped) May 5 16:05:21 Thinkpad kernel: pid 752 (firefox), uid 1001: exited on signal 11 (core dumped) May 5 16:05:24 Thinkpad kernel: pid 755 (firefox), uid 1001: exited on signal 11 (core dumped) May 5 16:05:26 Thinkpad kernel: pid 754 (firefox), uid 1001: exited on signal 11 (core dumped) May 5 16:05:30 Thinkpad kernel: pid 753 (firefox), uid 1001: exited on signal 11 (core dumped) May 5 16:08:40 Thinkpad kernel: pid 765 (firefox), uid 1001: exited on signal 11 (core dumped) May 5 16:08:42 Thinkpad kernel: pid 769 (firefox), uid 1001: exited on signal 11 (core dumped) May 5 16:08:45 Thinkpad kernel: pid 767 (firefox), uid 1001: exited on signal 11 (core dumped) May 5 16:08:46 Thinkpad kernel: pid 773 (firefox), uid 1001: exited on signal 11 (core dumped) I would go to ESR, but unfortunately, my .mozilla profile is too far removed from it already.
Comment 43 Jan Beich 2018-05-05 15:02:17 UTC
(In reply to jakub_lach from comment #41) As in "not much" details to help troubleshooting? Get a backtrace, try the binary package, try in a jail or different machine, try a fresh profile, try to disable e10s, find another user with the same issue. I don't see crashes on FreeBSD 10.4 i386. Mozilla doesn't test on FreeBSD at all and there's no automated crash reporting or telemetry to fall back on. Hoping the issue would disappear on its own by release announcement is often pointless. Otherwise, even Nightly on FreeBSD is stable enough for daily usage sans occasional bustage.
Comment 44 Jan Beich 2018-05-05 15:27:35 UTC
(In reply to jakub_lach from comment #42) > May 5 16:05:18 Thinkpad kernel: pid 750 (firefox), uid 1001: exited on signal 11 (core dumped) > May 5 16:05:21 Thinkpad kernel: pid 752 (firefox), uid 1001: exited on signal 11 (core dumped) > May 5 16:05:24 Thinkpad kernel: pid 755 (firefox), uid 1001: exited on signal 11 (core dumped) Only content processes crash? Does it happen on every site or those that contain certain (e.g., audio/video) elements? If the latter make sure firefox dependencies are also up to date: ffmpeg, libvpx, harfbuzz, etc.
Comment 45 jakub_lach 2018-05-05 16:24:43 UTC
Yes, as in "not much" in terms of troubleshooting. The profile was remade from scratch a month or so ago. If I get something more substantial, I will get back to you. It's a 11-STABLE amd64, ports are up do date.
Comment 46 jakub_lach 2018-05-05 23:51:22 UTC
(In reply to jakub_lach from comment #45) What do I now know, - premade binary package crashes too - fresh profile also What triggers it? Can't point a finger, but multiple YouTube videos (50+) and closing a Firefox is a good bet (cannot exit cleanly, that was a fresh profile and a package from ports). Sometime it's only a single tab and it does not take whole Firefox down, but both kinds really. Last time I needed bt from Firefox (a few years ago) I remember I needed to turn DEBUG on a lot of things (it was gstreamer iirc and it went away by itself).
Comment 47 Graham Perrin 2018-05-06 01:43:34 UTC
> 60.0,1 looking good to me, thanks. More specifically: - 60.0,1 - e10s enabled - HP EliteBook 8570p with 16 GB memory, <https://wiki.freebsd.org/Laptops/HP_EliteBook_8570p> - FreeBSD-CURRENT, $ uname -v FreeBSD 12.0-CURRENT #0 r333193: Thu May 3 10:59:06 BST 2018 root@momh167-gjp4-hpelitebook8570p-freebsd:/usr/obj/usr/src/amd64.amd64/sys/GENERIC ---- I pushed harder. e10s disabled (browser.tabs.remote.force-disable), to tell whether the app would crash. 1,245 tabs across fifteen windows, restored with Session Boss: OK. Then I browsed to a few other tabs, and quit. The same number of tabs, restored with the History menu: OK. An after effect of using Session Boss: if restoration is performed without Session Boss, then it may be necessary to manually load tabs. Disabled Session Boss, enabled Tab Session Manager, saved the session, quit. The same number, restored with Tab Session Manager: OK. Some restored tabs become blank when activated, re: <https://github.com/sienori/Tab-Session-Manager/issues/238> (not an issue with Tab Session Manager) it's an after-effect of using Session Boss: re: Added Tip Tab <https://addons.mozilla.org/addon/tip-tab/>, disabled Tab Session Manager, re-enabled Session Boss, re-enabled e10s, quit. The same number, restored with Session Boss: in progress. I'll revisit later, use Tip Tab to load some (restored) YouTube tabs.
Comment 48 Graham Perrin 2018-05-06 07:55:21 UTC
> … disabled Tab Session Manager, > re-enabled Session Boss, > re-enabled e10s, quit. … I forgot to re-enable e10s. > The same number, restored with Session Boss: … – was OK. > … use Tip Tab to load some (restored) YouTube tabs. Within the restored session I found (with Tip Tab) and loaded three YouTube videos. At some point during the session – maybe whilst the three videos played concurrently – there was, in response to a click on (or load of) a tab, _momentary_ appearance of a content process. The momentary multi-process surprised me, but I don't know whether it's a bug: - is it _ever_ appropriate to have more than one process when browser.tabs.remote.force-disable is true? I guess that Mozilla may invalidate any bug report that involves browser.tabs.remote.force-disable with Firefox Quantum. Jan, any thoughts? Would you like this spun off to a separate bug report in either the Mozilla or FreeBSD area? TIA
Comment 49 commit-hook 2018-05-07 20:33:53 UTC
A commit references this bug: Author: jbeich Date: Mon May 7 20:33:24 UTC 2018 New revision: 469334 URL: https://svnweb.freebsd.org/changeset/ports/469334 Log: MFH: r468751 r468754 r468985 r469332 www/firefox: update to 60.0 - Add U2F support, required by Web Authentication  - Drop libv4l support to reduce maintenance Changes: https://www.mozilla.org/firefox/60.0/releasenotes/ PR: 226476 Tested by: tobik, jrm, D. Ebdrup, lwhsu Submitted by: Greg V  Security: 5aefc41e-d304-4ec8-8c82-824f84f08244 Approved by: ports-secteam blanket Differential Revision: https://reviews.freebsd.org/D15186 Changes: _U branches/2018Q2/ branches/2018Q2/Mk/Uses/gecko.mk branches/2018Q2/Mk/bsd.gecko.mk branches/2018Q2/www/firefox/Makefile branches/2018Q2/www/firefox/distinfo branches/2018Q2/www/firefox/files/patch-bug1021761 branches/2018Q2/www/firefox/files/patch-bug1375074 branches/2018Q2/www/firefox/files/patch-bug1433747 branches/2018Q2/www/firefox/files/patch-bug1438678 branches/2018Q2/www/firefox/files/patch-bug1442583 branches/2018Q2/www/firefox/files/patch-bug1444083 branches/2018Q2/www/firefox/files/patch-bug1444798 branches/2018Q2/www/firefox/files/patch-bug1445907 branches/2018Q2/www/firefox/files/patch-bug1447359 branches/2018Q2/www/firefox/files/patch-bug1447925 branches/2018Q2/www/firefox/files/patch-bug1451292 branches/2018Q2/www/firefox/files/patch-bug1452041 branches/2018Q2/www/firefox/files/patch-bug1456556 branches/2018Q2/www/firefox/files/patch-bug826985 branches/2018Q2/www/firefox/files/patch-u2f-hid-rs62 branches/2018Q2/www/firefox/files/patch-z-bug1436911 branches/2018Q2/www/firefox/files/patch-z-bug517422 branches/2018Q2/www/firefox/pkg-message branches/2018Q2/www/firefox-i18n/Makefile branches/2018Q2/www/firefox-i18n/Makefile.lang branches/2018Q2/www/firefox-i18n/Makefile.option branches/2018Q2/www/firefox-i18n/distinfo
Comment 50 Jan Beich 2018-05-09 06:36:07 UTC
rc2 became release: https://hg.mozilla.org/releases/mozilla-release/rev/3202d5534730 (In reply to jakub_lach from comment #46) Can you try removing files/patch-bug1438678 and files/patch-z-bug1436911 ? Those improve how child processes are initialized and, normally, should've been part of 61.0. Did you toggle any prefs in about:config? In particular, gfx.xrender.enabled=true or layers.acceleration.force-enabled=true may degrade stability. Can you check about:support what audio backend is used? There's no perfect one, each has issues. (In reply to Graham Perrin from comment #48) > Would you like this spun off to a separate bug report in > either the Mozilla or FreeBSD area? Try bug 227850 then check on Linux and macOS. FreeBSD uses posix_spawn (like macOS) to create child processes. It wouldn't hurt to file a bug on Mozilla tracker but "_momentary_ appearance of a content process" may be a normal behavior given Firefox keeps the number of content processes limited (unlike Chromium).
Comment 51 commit-hook 2018-05-09 20:32:59 UTC
A commit references this bug: Author: jbeich Date: Wed May 9 20:32:25 UTC 2018 New revision: 469467 URL: https://svnweb.freebsd.org/changeset/ports/469467 Log: security/vuxml: mark firefox < 60 as vulnerable PR: 226476 Changes: head/security/vuxml/vuln.xml
Comment 52 jakub_lach 2018-05-09 22:39:13 UTC
(In reply to Jan Beich from comment #50) > Can you try removing files/patch-bug1438678 and files/patch-z-bug1436911 ? Recompiling without now. I have long streaks of stable use and long streaks of coredumps, still cannot isolate the cause precisely. >Did you toggle any prefs in about:config? In particular, >gfx.xrender.enabled=true or layers.acceleration.force-enabled=true may degrade >stability. No, I did most of my testing with my daily profile, but neither that nor fresh clean profile (which I've also crashed) has that set. >Can you check about:support what audio backend is used? Alsa Thanks for your attention :)
Comment 53 jakub_lach 2018-05-11 19:13:16 UTC
(In reply to jakub_lach from comment #52) > Can you try removing files/patch-bug1438678 and files/patch-z-bug1436911 ? Crashed version compiled without these too, albeit just once. I'll try to provide bt once I've recompile with debug.
Comment 54 jakub_lach 2018-05-11 21:30:49 UTC
86_64-unknown-freebsd/debug/libgkrust.a(std-618faf8e489f63eb.std4-60b51645c042d75ec977e9128499131e.rs.rcgu.o):std4-60b51645c042d75ec977e9128499131e.rs:function std::sys::unix::process::process_inner::<impl std::sys::unix::process::process_common::Command>::do_exec: warning: undefined reference to 'environ' c++: error: unable to execute command: Bus error (core dumped) c++: error: linker command failed due to signal (use -v to see invocation) gmake: *** [/usr/obj/usr/ports/www/firefox/work/firefox-60.0/config/rules.mk:701: libxul.so] Error 254 gmake: Leaving directory '/usr/obj/usr/ports/www/firefox/work/.build/toolkit/library' gmake: *** [/usr/obj/usr/ports/www/firefox/work/firefox-60.0/config/recurse.mk:73: toolkit/library/target] Error 2 gmake: Leaving directory '/usr/obj/usr/ports/www/firefox/work/.build' gmake: *** [/usr/obj/usr/ports/www/firefox/work/firefox-60.0/config/recurse.mk:33: compile] Error 2 gmake: Leaving directory '/usr/obj/usr/ports/www/firefox/work/.build' gmake: *** [/usr/obj/usr/ports/www/firefox/work/firefox-60.0/config/rules.mk:434: all] Error 2 gmake: Leaving directory '/usr/obj/usr/ports/www/firefox/work/.build' ===> Compilation failed unexpectedly. Unfortunately linker failed in DEBUG, FreeBSD 11.2-PRERELEASE #0 r333148 amd64, all options unchecked beside FFMPEG, DEBUG, OPTIMIZED, ALSA
Comment 55 Jan Beich 2018-05-12 10:16:04 UTC
--enable-debug enables assertions, runtime checks and disables optimizations. None of which have been tested on FreeBSD. For gdb/lldb only debug symbols and frame pointer are required e.g., $ env CFLAGS=-g make clean all STRIP= WITHOUT="DEBUG DTRACE OPTIMIZED_CFLAGS" -C /usr/ports/www/firefox or $ make clean all WITH_DEBUG= WITHOUT="DEBUG DTRACE OPTIMIZED_CFLAGS" -C /usr/ports/www/firefox
Comment 56 Jan Beich 2018-05-12 10:22:19 UTC
OPTIMIZED_CFLAGS passes -fomit-frame-pointer unless DEBUG, DTRACE or PROFILE are enabled.
Comment 57 jakub_lach 2018-05-12 12:30:29 UTC
(In reply to Jan Beich from comment #55) > $ make clean all WITH_DEBUG= WITHOUT="DEBUG DTRACE OPTIMIZED_CFLAGS" -C /usr/ports/www/firefox During linking unfortunately ld went pfault and ate 8GB of RAM and 4GB of swap, looked hopeless, so I've terminated it.
Comment 58 Jan Beich 2018-05-12 15:11:48 UTC
(In reply to jakub_lach from comment #57) Try building firefox with non-debug symbols and frame pointer. Get a backtrace then rebuild the affected functions with debug symbols. If backtrace looks corrupted or incomplete rebuild every library dependency with debug symbols, including libc/libthr/rtld.
Comment 59 commit-hook 2018-05-16 22:17:50 UTC
A commit references this bug: Author: jbeich Date: Wed May 16 22:17:01 UTC 2018 New revision: 470155 URL: https://svnweb.freebsd.org/changeset/ports/470155 Log: www/firefox: update to 60.0.1 Changes: https://www.mozilla.org/firefox/60.0.1/releasenotes/ PR: 226476 Changes: head/www/firefox/Makefile head/www/firefox/distinfo head/www/firefox-i18n/Makefile head/www/firefox-i18n/distinfo
Comment 60 commit-hook 2018-05-16 22:19:57 UTC
A commit references this bug: Author: jbeich Date: Wed May 16 22:19:47 UTC 2018 New revision: 470156 URL: https://svnweb.freebsd.org/changeset/ports/470156 Log: MFH: r470155 www/firefox: update to 60.0.1 Changes: https://www.mozilla.org/firefox/60.0.1/releasenotes/ PR: 226476 Approved by: ports-secteam blanket Changes: _U branches/2018Q2/ branches/2018Q2/www/firefox/Makefile branches/2018Q2/www/firefox/distinfo branches/2018Q2/www/firefox-i18n/Makefile branches/2018Q2/www/firefox-i18n/distinfo
Comment 61 Jan Beich 2018-05-25 16:17:22 UTC
(In reply to Li-Wen Hsu from comment #32) > Sadly, Google Handouts still doesn't work. Can you try again? https://old.reddit.com/r/firefox/comments/8leqgb/firefox_is_now_supported_by_google_hangouts_and/
Comment 62 commit-hook 2018-06-06 18:19:33 UTC
A commit references this bug: Author: jbeich Date: Wed Jun 6 18:18:58 UTC 2018 New revision: 471865 URL: https://svnweb.freebsd.org/changeset/ports/471865 Log: www/firefox: update to 60.0.2 Changes: https://www.mozilla.org/firefox/60.0.2/releasenotes/ PR: 226476 Changes: head/www/firefox/Makefile head/www/firefox/distinfo head/www/firefox-i18n/Makefile head/www/firefox-i18n/distinfo
Comment 63 commit-hook 2018-06-06 18:26:45 UTC
A commit references this bug: Author: jbeich Date: Wed Jun 6 18:26:06 UTC 2018 New revision: 471869 URL: https://svnweb.freebsd.org/changeset/ports/471869 Log: MFH: r471865 www/firefox: update to 60.0.2 Changes: https://www.mozilla.org/firefox/60.0.2/releasenotes/ PR: 226476 Approved by: ports-secteam blanket Changes: _U branches/2018Q2/ branches/2018Q2/www/firefox/Makefile branches/2018Q2/www/firefox/distinfo branches/2018Q2/www/firefox-i18n/Makefile branches/2018Q2/www/firefox-i18n/distinfo
Comment 64 jakub_lach 2018-09-05 08:49:03 UTC
(In reply to jakub_lach from comment #41) It looks like those finally ceased after clang update to 6.