This bug was filed from the Socorro interface and is report bp-0f0a12f2-60ad-413b-943c-9e4d20180216. ============================================================= Top 7 frames of crashing thread: 0 xul.dll nsHostResolver::GetHostToLookup netwerk/dns/nsHostResolver.cpp:1339 1 xul.dll nsHostResolver::ThreadFunc netwerk/dns/nsHostResolver.cpp:1797 2 nss3.dll PR_NativeRunThread nsprpub/pr/src/threads/combined/pruthr.c:397 3 nss3.dll pr_root nsprpub/pr/src/md/windows/w95thred.c:137 4 ucrtbase.dll __crt_stdio_output::crop_zeroes 5 @0xf00a2 6 ntdll.dll RtlUserThreadStart ============================================================= There is 1 crash in nightly 60 with buildid 20180216104033. In analyzing the backtrace, the regression may have been introduced by patch [1] to fix bug 1434852. [1] https://hg.mozilla.org/mozilla-central/rev?node=6776d69d2f03

I see one Mac crash - https://crash-stats.mozilla.com/report/index/c9193157-76a5-45fc-a5d0-81abe0180216 that is in networking that has the same build ID and no other crashes - not sure if it is related as well since I cannot tell for sure by looking at the stack.

Marcia, I'm pretty sure that mac crash is different since it has a completely different stack and is not related to name resolving at all. This bug looks TRR related.

I checked it closer, and we've had this crash reported earlier as well since way before TRR was merged so I don't think we can blame TRR for this. Possibly it might've changed the frequency or something. I think we need to see how this develops.

This is the #3 Windows topcrash in Nightly 20180216104033.

The GetHostToLookup signature spikes in nightly since February 16th.

bp-b94a5331-0b0d-4e21-a0dc-9d3ac0180220 nsHostResolver::GetHostToLookup waking laptop from sleep (approximately)

Eagerly waiting to see how bug 1439538 changes or does not change the frequency of these crashes going forward. I believe it is included in nightly 20180221102240.

(In reply to Wayne Mery (:wsmwk) from comment #6) > bp-b94a5331-0b0d-4e21-a0dc-9d3ac0180220 nsHostResolver::GetHostToLookup > waking laptop from sleep (approximately) Now two crashes in two days - crashed in similar circumstances RtlpWaitOnCriticalSection | RtlEnterCriticalSection | mozilla::MonitorAutoLock::MonitorAutoLock bp-cbb1f7f3-6fdd-4fc7-9ea0-133320180221 buildid 20180216223539 0 ntdll.dll RtlpWaitOnCriticalSection 1 ntdll.dll RtlEnterCriticalSection 2 xul.dll mozilla::MonitorAutoLock::MonitorAutoLock(mozilla::Monitor&) xpcom/threads/Monitor.h:78 3 xul.dll nsHostResolver::CompleteLookup(nsHostRecord*, nsresult, mozilla::net::AddrInfo*, bool) netwerk/dns/nsHostResolver.cpp:1598 4 xul.dll nsHostResolver::ThreadFunc(void*) netwerk/dns/nsHostResolver.cpp:1852 Will try tomorrow's build.

That crash (comment #8) looks more like bug 1439096 though. Related, but not the same.

It looks like these crashes have stopped, last ones were on 20180220103456 which matches "last release without" on https://hg.mozilla.org/mozilla-central/rev/58a485627c5e (bug 1439538).

Yeps. Let's keep this under observation for a little while longer before we call success but it certainly appears to have been fixed.

buildID 20180220103456 is still the last one to show up in the crash reports, so I think we can safely conclude that bug 1439538 fixed it.