1438904 - Crash in nsHostResolver::GetHostToLookup

Status: RESOLVED FIXED

(Core :: Networking: DNS, defect, P3)

Description

[Calixte Denizet (:calixte)]

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

Comment 1

[Marcia Knous [:marcia]]

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.

Comment 2

[Daniel Stenberg [:bagder]]

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.

Comment 3

[Daniel Stenberg [:bagder]]

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.

Comment 4

[Nicholas Nethercote [inactive]]

This is the #3 Windows topcrash in Nightly 20180216104033.

Comment 5

[Julien Cristau [:jcristau]]

The GetHostToLookup signature spikes in nightly since February 16th.

Comment 6

[Wayne Mery (:wsmwk)]

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

Comment 7

[Daniel Stenberg [:bagder]]

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.

Comment 8

[Wayne Mery (:wsmwk)]

(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.

Comment 9

[Daniel Stenberg [:bagder]]

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

Comment 11

[Julien Cristau [:jcristau]]

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).

Comment 12

[Daniel Stenberg [:bagder]]

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

Comment 13

[Valentin Gosu [:valentin] (he/him)]

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.