Ubuntu
firefox package

Crash after update to 71.0~b5+build1-0ubuntu0.16.04.1

Bug #1850529 reported by mark kowski
42
This bug affects 6 people
Affects Status Importance Assigned to Milestone
Mozilla Firefox
Won't Fix
Medium
firefox (Ubuntu)
Fix Released
Critical
Olivier Tilloy

Bug Description

After update from: 70.0+build2-0ubuntu0.16.04.1 to 71.0~b5+build1-0ubuntu0.16.04.1 app is not starting. I got constantly message that I can Refresh Firefox (crash) or Start in safe mode (also crash).

Tech details:
Description: Ubuntu 16.04.6 LTS
Release: 16.04
package name: 71.0~b5+build1-0ubuntu0.16.04.1

Crash log details:
AdapterDeviceID: 0x1616
AdapterDriverVendor: mesa/i965
AdapterDriverVersion: 18.0.5.0
AdapterVendorID: 0x8086
BuildID: 20191028161640
ContentSandboxCapabilities: 119
ContentSandboxCapable: 1
ContentSandboxLevel: 4
CrashTime: 1572373123
DOMIPCEnabled: 1
FramePoisonBase: 9223372036600930304
FramePoisonSize: 4096
InstallTime: 1572364967
IsWayland: 0
IsWaylandDRM: 0
MozCrashReason: MOZ_RELEASE_ASSERT(len.isValid()) (Substring tuple length is invalid)
Notes: Ubuntu 16.04.6 LTSFP(D00-L1000-W00000000-T000) WR? WR- OMTP? OMTP-
ProductID: {ec8030f7-c20a-464f-9b0e-13a3a9e97384}
ProductName: Firefox
ReleaseChannel: beta
SafeMode: 1
SecondsSinceLastCrash: 816
StartupCrash: 0
StartupTime: 1572373025
TelemetryEnvironment: {"build":{"applicationId":"{ec8030f7-c20a-464f-9b0e-13a3a9e97384}","applicationName":"Firefox","architecture":"x86-64","buildId":"20191028161640","version":"71.0","vendor":"Mozilla","displayVersion":"71.0b5","platformVersion":"71.0","xpcomAbi":"x86_64-gcc3","updaterAvailable":false},"partner":{"distributionId":null,"distributionVersion":null,"partnerId":null,"distributor":null,"distributorChannel":null,"partnerNames":[]},"system":{"memoryMB":15965,"virtualMaxMB":null,"cpu":{"count":4,"cores":2,"vendor":"GenuineIntel","family":6,"model":61,"stepping":4,"l2cacheKB":256,"l3cacheKB":3072,"speedMHz":2700,"extensions":["hasMMX","hasSSE","hasSSE2","hasSSE3","hasSSSE3","hasSSE4_1","hasSSE4_2","hasAVX","hasAVX2","hasAES"]},"os":{"name":"Linux","version":"4.15.0-66-generic","locale":"en-US"},"hdd":{"profile":{"model":null,"revision":null,"type":null},"binary":{"model":null,"revision":null,"type":null},"system":{"model":null,"revision":null,"type":null}},"gfx":{"D2DEnabled":null,"DWriteEnabled":null,"ContentBackend":"Skia","Headless":false,"adapters":[{"description":"Mesa DRI Intel(R) HD Graphics 5500 (Broadwell GT2) ","vendorID":"0x8086","deviceID":"0x1616","subsysID":null,"RAM":3072,"driver":null,"driverVendor":"mesa/i965","driverVersion":"18.0.5.0","driverDate":null,"GPUActive":true}],"monitors":[{"screenWidth":1366,"screenHeight":768}],"features":{"compositor":"none","gpuProcess":{"status":"blocked"},"wrQualified":{"status":"blocked-release-channel-intel"},"webrender":{"status":"unavailable-in-safe-mode"}}},"appleModelId":null},"settings":{"blocklistEnabled":true,"e10sEnabled":true,"e10sMultiProcesses":8,"telemetryEnabled":true,"locale":"en-US","intl":{},"update":{"channel":"beta","enabled":true,"autoDownload":false},"userPrefs":{"app.shield.optoutstudies.enabled":false,"browser.cache.disk.capacity":1048576,"browser.newtabpage.enabled":false,"browser.shell.checkDefaultBrowser":true,"browser.search.region":"US","browser.search.suggest.enabled":false,"browser.search.widget.inNavBar":false,"browser.startup.homepage":"<user-set>","browser.startup.page":3,"browser.urlbar.suggest.searches":false,"devtools.chrome.enabled":false,"devtools.debugger.remote-enabled":false,"extensions.blocklist.url":"https://blocklists.settings.services.mozilla.com/v1/blocklist/3/%20/%20/","extensions.formautofill.addresses.enabled":false,"extensions.formautofill.creditCards.enabled":false,"privacy.donottrackheader.enabled":true},"sandbox":{"effectiveContentProcessLevel":4},"addonCompatibilityCheckEnabled":true,"isDefaultBrowser":null},"profile":{}}
ThreadIdNameMapping: 7556:"Gecko_IOThread",7557:"JS Watchdog",7558:"JS Helper",7559:"JS Helper",7560:"JS Helper",7561:"JS Helper",7562:"Timer",7563:"Netlink Monitor",7564:"Socket Thread",7568:"Cache2 I/O",7569:"Cookie",7570:"StreamTrans #1",7571:"GMPThread",7572:"Worker Launcher",7573:"SoftwareVsyncThread",7574:"Compositor",7575:"ImgDecoder #1",7576:"ImageIO",7580:"ImageBridgeChild",7581:"IPDL Background",7582:"DOM Worker",7584:"QuotaManager IO",7587:"StyleThread#0",7589:"StyleThread#2",7588:"StyleThread#1",7593:"DOM Worker",7630:"DataStorage",7631:"DNS Resolver #1",7632:"DNS Resolver #2",7633:"StreamTrans #7",7646:"IndexedDB #2",7647:"StreamTrans #8",7648:"StreamTrans #9",7649:"StreamTrans #10",
Throttleable: 1
UptimeTS: 98.30915265
Vendor: Mozilla
Version: 71.0
useragent_locale: en-US

Revision history for this message
mark kowski (markowski1) wrote :

Also I attach crash report from fiferox/profile/crashes folder (I don't know if it helps but more info is better).

Revision history for this message
Launchpad Janitor (janitor) wrote :

Status changed to 'Confirmed' because the bug affects multiple users.

Changed in firefox (Ubuntu):
status: New → Confirmed
Revision history for this message
Greg Whiteley (greg-whiteley) wrote :

Can confirm same issue here - also 16.04 x86_64 - also tried creating a new (clean) profile, but that does not resolve the issue.

I've reverted off the beta/next ppa back to "70.0+build2-0ubuntu0.16.04.1", but can't use my old profile as reverting profiles isn't allowed

Revision history for this message
Greg Whiteley (greg-whiteley) wrote :

Apologies if I've incorrectly duplicated here - I've logged a separate bug to ensure there is a full AppPort bundle as suggested in the firefox bug wiki page.

https://bugs.launchpad.net/ubuntu/+source/firefox/+bug/1850597

Revision history for this message
mark kowski (markowski1) wrote :

Also important information from my side (as above) - when I try to restore old version of app: 70.0+build2-0ubuntu0.16.04.1 - I have information that my profile files are too old and aren't compatible anymore. So beside update from 70 to 71 - there is something wrong with profile files inconsistency.

Revision history for this message
Olivier Tilloy (osomon) wrote :

I can reliably reproduce the crash in a 16.04 VM. The crash doesn't occur on 18.04.

Note that this is a beta version of firefox, so use at your own risk (but the crash will be investigated indeed, thanks for the report!).

Profile incompatibility when downgrading is to be expected. Profiles are only forward-compatible.

Changed in firefox (Ubuntu):
importance: Undecided → Medium
Revision history for this message
Olivier Tilloy (osomon) wrote :

For reference, upstream builds of firefox 71.0 beta 5 are not crashing in the same xenial VM.

Revision history for this message
mark kowski (markowski1) wrote :

Thanks for info - I didn't know that profiles are forward-compatible only.

Revision history for this message
baptiste (baptiste-goupil) wrote :

I confirm the same issue on 16.04. Firefox is now entirely unusable.

Revision history for this message
j127 (j127) wrote :

This broke Firefox for me on 16.04 tonight. Has anyone found a temporary fix? (It's my main browser with all of my tabs and extension data.)

If "upstream builds of firefox 71.0 beta 5" might work in the meantime, does anyone know how to install it?

Revision history for this message
j127 (j127) wrote :

Also, if this version is known to be broken, maybe it should be removed for 16.04 users so that it doesn't happen to anyone else? My computer downloaded it six days after it was confirmed to be broken.

Revision history for this message
Olivier Tilloy (osomon) wrote :

j127: if you're using the firefox-next PPA, you're doing this at your own risk, without any guarantees from ubuntu developers that this won't break. The PPA is meant for testing beta builds, not for end users.

If you want a stable version of firefox, you shouldn't be using that PPA. Packages in the Ubuntu archive are supported.

Revision history for this message
Olivier Tilloy (osomon) wrote :

Still crashing with 71.0~b7+build1-0ubuntu0.16.04.1, FWIW.

Revision history for this message
mark kowski (markowski1) wrote :

Yep - fully agree - beta for testing (or for hardcore daily users ;). Any chances for fix anytime soon anyway?

@j127 - downgrade to latest stable version, find your profile folder (about:profiles), open the folder with your new profile and copy/paste proper files from old profile (passwords, database, cookies, history, bookmarks): https://support.mozilla.org/en-US/kb/profiles-where-firefox-stores-user-data.
Close browser, run again and you have temporary solution for using part of your private data on old version of FF. As mentioned above - you can't use your full new profile folder with older version of FF so you need to manually overwrite dedicated files.
Hope it helps :)!

Revision history for this message
j127 (j127) wrote :

Thanks, I already downgraded, but the data I need is in the browser extensions, so I'll look around in those directories. I have three separate Firefox profiles there that I use on a daily basis.

I still think that if it's known to be broken, it should be removed so that no one else downloads it. I don't mind if things break occasionally, but I didn't expect it to break for many days at a time. I was using the beta version to see new features in advance so I can provide feedback to Mozilla. I'm a long-time Firefox user and supporter (since Mozilla Application Suite).

Revision history for this message
j127 (j127) wrote :

It looks like the only way to get the extension data out of the old Firefox profiles is to query some sqlite databases that are located in `<profile_dir>/storage/default`. I found one of the important extension directories, but querying the database just returns gibberish.

For anyone else dealing with the problem, I'm wondering if it might be solvable by booting Ubuntu 18.04 from a thumb drive, installing the nightly Firefox version in it, loading the profiles there, exporting any needed data via the extension settings, and then importing it back into the stable version after booting from the hard drive again. I'll try it tomorrow.

Revision history for this message
mark kowski (markowski1) wrote :

Also interesting idea - especially if you need data from extensions (which I miss too and I didn't try to recover). Also +1 for blocking/removing this build from download sources. It's too dangerous for now ;).

Revision history for this message
Olivier Tilloy (osomon) wrote :

At the risk of repeating myself: the firefox-next PPA is not intended for production use, only for preview testing of the upcoming version of firefox. Use at your own risk, or don't use it at all. This is not the regular Ubuntu archive.

Revision history for this message
In , Mats-l (mats-l) wrote :
Download full text (4.3 KiB)

Starting it under gdb shows that it crashes due to infinite recursion copying a string:

(gdb) bt
#0 0x00007fffe443ab5d in mozilla::detail::nsTStringRepr<char>::nsTStringRepr(char*, unsigned int, mozilla::detail::StringDataFlags, mozilla::detail::StringClassFlags) (this=<optimized out>, aData=0x7fffea2099c4 <gNullChar> "", aLength=0, aDataFlags=mozilla::detail::StringDataFlags::TERMINATED, aClassFlags=mozilla::detail::StringClassFlags::NULL_TERMINATED) at xpcom/string/nsTStringRepr.h:322
#1 0x00007fffe443ab5d in nsTSubstring<char>::nsTSubstring(mozilla::detail::StringClassFlags) (this=<optimized out>, aClassFlags=mozilla::detail::StringClassFlags::NULL_TERMINATED) at xpcom/string/nsTSubstring.h:1142
#2 0x00007fffe443ab5d in nsTString<char>::nsTString(nsTSubstringTuple<char> const&) (this=<optimized out>, aTuple=...) at xpcom/string/nsTString.h:95
#3 0x00007fffe443ab5d in nsTSubstring<char>::Assign(nsTSubstringTuple<char> const&, std::nothrow_t const&) (this=0x7fffdf6bf040, aTuple=..., aFallible=...) at xpcom/string/nsTSubstring.cpp:556
#4 0x00007fffe443ab82 in nsTSubstring<char>::Assign(nsTSubstringTuple<char> const&) (this=0x7fffea2099c4 <gNullChar>, aTuple=...) at xpcom/string/nsTSubstring.cpp:546
#5 0x00007fffe443ab82 in nsTString<char>::nsTString(nsTSubstringTuple<char> const&) (this=0x7fffea2099c4 <gNullChar>, aTuple=...) at xpcom/string/nsTString.h:96
#6 0x00007fffe443ab82 in nsTSubstring<char>::Assign(nsTSubstringTuple<char> const&, std::nothrow_t const&) (this=0x7fffdf6bf090, aTuple=..., aFallible=...) at xpcom/string/nsTSubstring.cpp:556
#7 0x00007fffe443ab82 in nsTSubstring<char>::Assign(nsTSubstringTuple<char> const&) (this=0x7fffea2099c4 <gNullChar>, aTuple=...) at xpcom/string/nsTSubstring.cpp:546
#8 0x00007fffe443ab82 in nsTString<char>::nsTString(nsTSubstringTuple<char> const&) (this=0x7fffea2099c4 <gNullChar>, aTuple=...) at xpcom/string/nsTString.h:96
#9 0x00007fffe443ab82 in nsTSubstring<char>::Assign(nsTSubstringTuple<char> const&, std::nothrow_t const&) (this=0x7fffdf6bf0e0, aTuple=..., aFallible=...) at xpcom/string/nsTSubstring.cpp:556
#10 0x00007fffe443ab82 in nsTSubstring<char>::Assign(nsTSubstringTuple<char> const&) (this=0x7fffea2099c4 <gNullChar>, aTuple=...) at xpcom/string/nsTSubstring.cpp:546
#11 0x00007fffe443ab82 in nsTString<char>::nsTString(nsTSubstringTuple<char> const&) (this=0x7fffea2099c4 <gNullChar>, aTuple=...) at xpcom/string/nsTString.h:96
#12 0x00007fffe443ab82 in nsTSubstring<char>::Assign(nsTSubstringTuple<char> const&, std::nothrow_t const&) (this=0x7fffdf6bf130, aTuple=..., aFallible=...) at xpcom/string/nsTSubstring.cpp:556
#13 0x00007fffe443ab82 in nsTSubstring<char>::Assign(nsTSubstringTuple<char> const&) (this=0x7fffea2099c4 <gNullChar>, aTuple=...) at xpcom/string/nsTSubstring.cpp:546
#14 0x00007fffe443ab82 in nsTString<char>::nsTString(nsTSubstringTuple<char> const&) (this=0x7fffea2099c4 <gNullChar>, aTuple=...) at xpcom/string/nsTString.h:96
#15 0x00007fffe443ab82 in nsTSubstring<char>::Assign(nsTSubstringTuple<char> const&, std::nothrow_t const&) (this=0x7fffdf6bf180, aTuple=..., aFallible=...) at xpcom/string/nsTSubstring.cpp:556
#16 0x00007fffe443ab82 in nsTSubstring<char>::As...

Read more...

Revision history for this message
In , Mats-l (mats-l) wrote :

I'm guessing the above code is miscompiled for some reason.
I use the default clang on my system. Is this version not supported anymore?

```
# /usr/bin/clang --version
clang version 6.0.0-1ubuntu2 (tags/RELEASE_600/final)
Target: x86_64-pc-linux-gnu
Thread model: posix
InstalledDir: /usr/bin
```

Revision history for this message
In , Mats-l (mats-l) wrote :

This is on "Ubuntu 18.04.3 LTS".

Revision history for this message
In , Mats-l (mats-l) wrote :

Problem solved by removing:
```
export CC=/usr/bin/clang
export CXX=/usr/bin/clang++
```
from my .mozconfig file. Then the build defaulted to use a newer clang I had under `$HOME/.mozbuild/clang/bin/`

I'll leave this bug open anyway in case clang-6 is supposed to be supported.

Revision history for this message
In , Erahm (erahm) wrote :

dmajor pointed out that there are known miscompilation issues with clang-6 that we've [patched for our version](https://hg.mozilla.org/mozilla-central/log/5f1704e88fa79ad4156497de208c87c58a228ca2/build/build-clang/clang-6-linux64.json) that we use in automation. I'm not sure there's much to do here but maybe add a check for clang-6.0.0 and refuse to build?

Revision history for this message
In , Dmajor-1 (dmajor-1) wrote :

If the clang-6 is one from taskcluster (say, if it's in .mozbuild) then it might still work...

Revision history for this message
baptiste (baptiste-goupil) wrote :

We know that but that does not mean it shouldn't be fixed if this version is supposed to be released at some point ;-)

Still crashing on 71.0~b8+build1-0ubuntu0.16.04.1 with the same assert error (MozCrashReason: MOZ_RELEASE_ASSERT(len.isValid()) (Substring tuple length is invalid)).

Revision history for this message
j127 (j127) wrote :

I managed to extract my data from the extensions using the technique I mentioned in comment #16 above. The process took hours but it worked. If anyone else's extension data is locked up, try that.

Bug Watch Updater (bug-watch-updater)
Changed in firefox:
importance: Unknown → Medium
status: Unknown → Confirmed
Revision history for this message
baptiste (baptiste-goupil) wrote :

Simpler than j127's solution is to download the last beta on https://download.mozilla.org/?product=firefox-beta-latest-ssl&os=linux64&lang=en-US, copy your profile into a new folder, then launch the executable with `MOZ_ALLOW_DOWNGRADE=1 /home/baptiste/firefox/firefox -P`, create a profile and choose the copied folder. All works smoothly and it takes 5mn.

Revision history for this message
In , Simon Giesecke (sgiesecke) wrote :

*** Bug 1592571 has been marked as a duplicate of this bug. ***

Revision history for this message
Simon Giesecke (sgiesecke) wrote :

In https://bugzilla.mozilla.org/show_bug.cgi?id=1592571, which is currently identified as a duplicate of https://bugzilla.mozilla.org/show_bug.cgi?id=1594686, it was pointed out that this is probably due to bad code generation by clang 6. Two patches for clang 6 which seem to be required to generate correct code (in particular in the context of nsTSubstringTuple) appear to be:
* https://hg.mozilla.org/mozilla-central/rev/0d04a3f89940536d56cd5415a78316f0960e9f0a (if not already compiling with 6.0.1)
* https://hg.mozilla.org/mozilla-central/rev/dfe8ab123e01667be489a20b253e3cd3b20c10bd

Since this might also affect products other than firefox, it might make sense to apply these patches to Ubuntu's clang 6 packages in general.

Revision history for this message
In , Emilio (emiliocobos) wrote :

*** Bug 1600467 has been marked as a duplicate of this bug. ***

Revision history for this message
In , Emilio (emiliocobos) wrote :

Can we add a configure check for this somehow? It seems ubuntu almost ships a build with this bug, see bug 1600467... :/

Revision history for this message
Olivier Tilloy (osomon) wrote :

I backported clang 1:6.0.1-11 from disco to xenial in a PPA and rebuilt firefox 71.0+build4 against it, but the crash still occurs at startup.

Version 1:6.0.1-11 from disco doesn't have https://hg.mozilla.org/mozilla-central/rev/0d04a3f89940536d56cd5415a78316f0960e9f0a, I'll test applying this patch.

Revision history for this message
Olivier Tilloy (osomon) wrote :

Applying that patch on top of 1:6.0.1-11 doesn't help, firefox 71.0+build4 still crashes at startup.

Revision history for this message
In , Olivier Tilloy (osomon) wrote :

This is being tracked by https://bugs.launchpad.net/ubuntu/+source/firefox/+bug/1850529 in Ubuntu.
Ubuntu 16.04 has clang 6.0, and as pointed out this is known to result in miscompilation issues, which for some reason haven't really surfaced until now (firefox 71). I have tested backporting clang 6.0.1 to Ubuntu 16.04 with all the patches listed in https://hg.mozilla.org/mozilla-central/file/5f1704e88fa79ad4156497de208c87c58a228ca2/build/build-clang/clang-6-linux64.json (as suggested in https://bugzilla.mozilla.org/show_bug.cgi?id=1592571#c11), but it didn't help.
I am considering attempting a backport of clang 8.

Please note that these Ubuntu builds (such as the one mentioned in https://bugzilla.mozilla.org/show_bug.cgi?id=1600467) are for testing purposes only, and the PPAs containing them (particularly https://launchpad.net/~ubuntu-mozilla-security/+archive/ubuntu/ppa) advertise that they are not meant for end users. Ubuntu developers do not intend to release a broken build of firefox to the Ubuntu archive.

Olivier Tilloy (osomon)
Changed in firefox (Ubuntu):
assignee: nobody → Olivier Tilloy (osomon)
importance: Medium → Critical
Revision history for this message
In , Emilio (emiliocobos) wrote :

Ah, thanks for the update Olivier :)

I think it'd still be nice to detect this at configure time if possible, but it may be not worth the churn.

Olivier Tilloy (osomon)
Changed in firefox (Ubuntu):
status: Confirmed → In Progress
Revision history for this message
In , Gijskruitbosch+bugs (gijskruitbosch+bugs) wrote :

*** Bug 1597006 has been marked as a duplicate of this bug. ***

Revision history for this message
In , Gijskruitbosch+bugs (gijskruitbosch+bugs) wrote :

(In reply to Emilio Cobos Álvarez (:emilio) from comment #10)
> Ah, thanks for the update Olivier :)
>
> I think it'd still be nice to detect this at configure time if possible, but it may be not worth the churn.

I agree - me and a gsoc student were stumped on this for close to a month, trying to figure out what was wrong with their setup. There's also been a succession of dupes filed.

Can we add a configure check to prevent building with clang 6 unless located in `.mozbuild` ?

Revision history for this message
In , Gijskruitbosch+bugs (gijskruitbosch+bugs) wrote :

Oops, wrong needinfo requestee.

(In reply to :Gijs (he/him) from comment #12)
> Can we add a configure check to prevent building with clang 6 unless located in `.mozbuild` ?

Revision history for this message
In , Cmanchester (cmanchester) wrote :

Yes I will find an assignee.

Revision history for this message
In , Cmanchester (cmanchester) wrote :

I'll take this. dmajor, does it seem worthwhile to explicitly check for the clang 6 from automation case? Just disallowing clang-6 seems more straightforward.

Revision history for this message
In , Dmajor-1 (dmajor-1) wrote :

(In reply to Chris Manchester (:chmanchester) from comment #15)
> I'll take this. dmajor, does it seem worthwhile to explicitly check for the clang 6 from automation case? Just disallowing clang-6 seems more straightforward.

So you're proposing that our clang requirement on Linux would be "5 or later, but not 6"? I don't have any objection, but double check with froydnj.

Revision history for this message
In , Nfroyd (nfroyd) wrote :

(In reply to :dmajor from comment #16)
> (In reply to Chris Manchester (:chmanchester) from comment #15)
> > I'll take this. dmajor, does it seem worthwhile to explicitly check for the clang 6 from automation case? Just disallowing clang-6 seems more straightforward.
>
> So you're proposing that our clang requirement on Linux would be "5 or later, but not 6"? I don't have any objection, but double check with froydnj.

Disallowing clang 6 entirely seems OK to me. Anybody who still has our automation-built clang 6 probably needs a kick to upgrade anyway. Please add a toolchain test to ensure that we detect clang 6 properly.

Revision history for this message
In , Mh+mozilla (mh+mozilla) wrote :

It's very possible this is the same as bug 1601707. If it is, we don't need to exclude clang 6.

Revision history for this message
In , Nfroyd (nfroyd) wrote :

(In reply to Mike Hommey [:glandium] (high latency) from comment #18)
> It's very possible this is the same as bug 1601707. If it is, we don't need to exclude clang 6.

OTOH, I don't want to be rediscovering that people are using a compiler that doesn't implement some finer point of C++17 (bug 1601707 comment 5) every couple of weeks or months, wasting time debugging, and rewriting the code to compensate.

Revision history for this message
In , Emilio (emiliocobos) wrote :

(In reply to Nathan Froyd [:froydnj] from comment #19)
> (In reply to Mike Hommey [:glandium] (high latency) from comment #18)
> > It's very possible this is the same as bug 1601707. If it is, we don't need to exclude clang 6.
>
> OTOH, I don't want to be rediscovering that people are using a compiler that doesn't implement some finer point of C++17 (bug 1601707 comment 5) every couple of weeks or months, wasting time debugging, and rewriting the code to compensate.

I think we should have _some_ gcc build running tests on automation, fwiw. Finding stuff like that or bug 1600735 the hard way is really painful :(

Revision history for this message
In , Emilio (emiliocobos) wrote :

Maybe even tier 2 / running on m-c only, or something?

Revision history for this message
In , Nfroyd (nfroyd) wrote :

(In reply to Emilio Cobos Álvarez (:emilio) from comment #20)
> (In reply to Nathan Froyd [:froydnj] from comment #19)
> > (In reply to Mike Hommey [:glandium] (high latency) from comment #18)
> > > It's very possible this is the same as bug 1601707. If it is, we don't need to exclude clang 6.
> >
> > OTOH, I don't want to be rediscovering that people are using a compiler that doesn't implement some finer point of C++17 (bug 1601707 comment 5) every couple of weeks or months, wasting time debugging, and rewriting the code to compensate.
>
> I think we should have _some_ gcc build running tests on automation, fwiw. Finding stuff like that or bug 1600735 the hard way is really painful :(

I totally agree about this stuff being super-painful to debug. But running GCC *and* clang base-toolchain tests might be a lot to ask. :(

Revision history for this message
In , Nfroyd (nfroyd) wrote :

(In reply to Emilio Cobos Álvarez (:emilio) from comment #21)
> Maybe even tier 2 / running on m-c only, or something?

I'll just note that as somebody who has had multiple patches backed out because of jobs that *only* run on central and those jobs aren't selectable by default by `mach try fuzzy` (or non-obviously selectable), I'd really not like to see us add more of "only run on m-c" jobs.

Revision history for this message
In , Mh+mozilla (mh+mozilla) wrote :

(In reply to Nathan Froyd [:froydnj] from comment #19)
> (In reply to Mike Hommey [:glandium] (high latency) from comment #18)
> > It's very possible this is the same as bug 1601707. If it is, we don't need to exclude clang 6.
>
> OTOH, I don't want to be rediscovering that people are using a compiler that doesn't implement some finer point of C++17 (bug 1601707 comment 5) every couple of weeks or months, wasting time debugging, and rewriting the code to compensate.

That specific comment explicitly says current GCC doesn't implement it. Are we going to require clang only now?

Revision history for this message
In , Nfroyd (nfroyd) wrote :

(In reply to Mike Hommey [:glandium] (high latency) from comment #24)
> (In reply to Nathan Froyd [:froydnj] from comment #19)
> > (In reply to Mike Hommey [:glandium] (high latency) from comment #18)
> > > It's very possible this is the same as bug 1601707. If it is, we don't need to exclude clang 6.
> >
> > OTOH, I don't want to be rediscovering that people are using a compiler that doesn't implement some finer point of C++17 (bug 1601707 comment 5) every couple of weeks or months, wasting time debugging, and rewriting the code to compensate.
>
> That specific comment explicitly says current GCC doesn't implement it. Are we going to require clang only now?

Can we bump the required version of GCC too? :)

I don't think we can drop GCC support just on that. Maybe we should just get a static checker for the string issue?

Revision history for this message
In , Emilio (emiliocobos) wrote :

(In reply to Mike Hommey [:glandium] (high latency) from comment #24)
> That specific comment explicitly says current GCC doesn't implement it. Are we going to require clang only now?

Well GCC just fixed it in fairness: https://gcc.gnu.org/viewcvs/gcc?view=revision&revision=279069

I think they would've fixed it much earlier if we would've found this on automation rather than after busting builds shipped by distros to a bunch of users... :)

I think supporting clang-only would be sad, IMHO. I use gcc builds from time to time for debugging, as they have better debug info.

(In reply to Nathan Froyd [:froydnj] from comment #23)
> I'll just note that as somebody who has had multiple patches backed out because of jobs that *only* run on central and those jobs aren't selectable by default by `mach try fuzzy` (or non-obviously selectable), I'd really not like to see us add more of "only run on m-c" jobs.

To be clear, I'd be more than happy with them running in all pushes :)

But if the automation cost is a concern, Tier2 + central-only shouldn't get anyone backed out, and should be cheaper, if I understand our backout policy correctly.

Revision history for this message
In , Cmanchester (cmanchester) wrote :

I ended up writing a patch for this. I'll post it in case we end up wanting to take it.

Revision history for this message
In , Cmanchester (cmanchester) wrote :

Created attachment 9115566
Bug 1594686 - Disallow building with clang-6.

Revision history for this message
In , Emilio (emiliocobos) wrote :

Someone on #introduction mentioned that https://phabricator.services.mozilla.com/D56873 did fix the problem for them.

Revision history for this message
Olivier Tilloy (osomon) wrote :

clang 8 was backported to xenial and firefox 71.0 rebuilt with it, and the crash is now fixed.

Changed in firefox (Ubuntu):
status: In Progress → Fix Released
Revision history for this message
In , Olivier Tilloy (osomon) wrote :

(In reply to Olivier Tilloy from comment #9)
> I am considering attempting a backport of clang 8.

I ended up backporting clang 8 to Ubuntu 16.04, and rebuilding firefox 71.0+build5 with it. The startup crash is gone, and that build was published to xenial-security and xenial-updates yesterday. So as far as Ubuntu is concerned, problem solved.

Revision history for this message
Pascal Mons (anton+) wrote :

Thank you Olivier for your effort and the information you provided me as well.

Revision history for this message
In , Cmanchester (cmanchester) wrote :

Un-assigning for now. There seem to be arguments for and against here, but if we're sure people aren't hitting this anymore this should be closed.

Revision history for this message
In , Kmoir (kmoir) wrote :

Closing

Bug Watch Updater (bug-watch-updater)
Changed in firefox:
status: Confirmed → Won't Fix
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Duplicates of this bug

Subscribing...

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.