Startup crash @ nsObserverService::AddObserver involving TRR

VERIFIED FIXED in Firefox 69

Status

()

defect
P1
critical
VERIFIED FIXED
2 months ago
Last month

People

(Reporter: rolyc5, Assigned: valentin.gosu)

Tracking

(Regression, {crash, regression})

69 Branch
mozilla69
Points:
---

Firefox Tracking Flags

(firefox-esr60 unaffected, firefox67 unaffected, firefox68 unaffected, firefox69blocking fixed)

Details

(Whiteboard: [necko-triaged][trr], crash signature)

Attachments

(1 attachment)

Crash reports:
https://crash-stats.mozilla.com/report/index/d36d8175-cd06-48c3-92f7-1a53e0190605
https://crash-stats.mozilla.com/report/index/7ca7ea5f-8fc0-4491-b859-17bc00190605
https://crash-stats.mozilla.com/report/index/733999b9-6fc4-4fc6-b1a6-b88f00190605

Firefox Nightly updated automatically in the background to 69.0a1 (2019-06-04). I restarted the browser using the hamburger menu's notification, and on relaunch, Nightly crashed under my regular profile. Nightly now crashes at launch every time.

Nightly does not crash with a clean profile.

Product: Socorro → Firefox
Version: unspecified → 69 Branch

You want to reset network.trr.mode to eliminate symptom.

Status: UNCONFIRMED → NEW
Crash Signature: [@ nsObserverService::AddObserver ]
Component: General → Networking: DNS
Ever confirmed: true
OS: macOS → All
Product: Firefox → Core
Hardware: x86_64 → All
Summary: Crash on startup: Nightly 2019-06-04 → Startup crash @ nsObserverService::AddObserver involving TRR
Severity: normal → critical
Keywords: crash, regression

[Tracking Requested - why for this release]:

Startup crash regression when using TRR (DoH).

(In reply to Ekanan Ketunuti from comment #1)

You want to reset network.trr.mode to eliminate symptom.

Does safe mode still use network.trr.mode? I was crashing on launch even when launching in safe mode. I had to manually edit my profile's prefs.js file and add user_pref("network.trr.mode", 0); to undo the pref.

Duplicate of this bug: 1556950
Assignee: nobody → valentin.gosu
Priority: -- → P1
Regressed by: 1518730
Whiteboard: [necko-triaged][trr]

This patch calls NetworkConnectivityService::GetSingleton() on the main thread
and keeps a ref to the service until shutdown.
Even though calling ncs->GetIPv6() off-main-thread is technically a data-race
in practice that's OK because only the simple decision whether to send
AAAA requests is made based on that value, which in itself is an optimization.
I filed bug 1556967 for making the connectivity service thread safe.

(In reply to Chris Peterson [:cpeterson] from comment #2)

Does safe mode still use network.trr.mode? I was crashing on launch even when launching in safe mode. I had to manually edit my profile's prefs.js file and add user_pref("network.trr.mode", 0); to undo the pref.

I feel like it should. In which component should I file the bug?

IIUC, safe mode has no effect on mod-prefs.

FWIW, I had to do the same as Chris.

As for the proposed change: https://software.intel.com/en-us/blogs/2013/01/06/benign-data-races-what-could-possibly-go-wrong

Duplicate of this bug: 1556988

I'm seeing a NetworkConnectivityService::GetSingleton() crash, but so far only when visiting https://blog.digitalocean.com/an-update-on-last-weeks-customer-shutdown-incident/ specifically :D

¡Hola!

Yup! Happened to me also on Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:69.0) Gecko/20100101 Firefox/69.0 ID:20190605095225:

bp-e32cb003-eac4-4c1c-a9cc-d1d920190605 6/5/2019, 8:27 AM

The 2nd start after the startup crash had no issue though.

The only modified about:config is:

network.trr.mode 2

¡Gracias!
Alex

(In reply to Martin Thomson [:mt:] from comment #7)

As for the proposed change: https://software.intel.com/en-us/blogs/2013/01/06/benign-data-races-what-could-possibly-go-wrong

Agreed. It's just that making the connectivity service thread safe would have taken longer than it took me to write up this patch.

Pushed by valentin.gosu@gmail.com:
https://hg.mozilla.org/integration/autoland/rev/0d39f4b9fe60
Don't instantiate NetworkConnectivityService off-main-thread r=dragana
Status: NEW → RESOLVED
Closed: 2 months ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla69

¡Hola!

The crash no longer occurs on Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:69.0) Gecko/20100101 Firefox/69.0 ID:20190609090758

¡Gracias!
Alex

Status: RESOLVED → VERIFIED
Duplicate of this bug: 1558199
You need to log in before you can comment on or make changes to this bug.