Closed Bug 1438904 Opened 2 years ago Closed 2 years ago

Crash in nsHostResolver::GetHostToLookup

Categories

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

Unspecified
Windows 7
defect

Tracking

()

RESOLVED FIXED
Tracking Status
firefox-esr52 --- unaffected
firefox58 --- unaffected
firefox59 --- unaffected
firefox60 + fixed

People

(Reporter: calixte, Assigned: bagder)

References

(Blocks 1 open bug)

Details

(Keywords: crash, regression, topcrash, Whiteboard: [necko-triaged][trr])

Crash Data

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
Flags: needinfo?(daniel)
Crash Signature: [@ nsHostResolver::GetHostToLookup] → [@ nsHostResolver::GetHostToLookup] [@ mozilla::net::AddrInfo::~AddrInfo]
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.
Assignee: nobody → daniel
Flags: needinfo?(daniel)
Priority: -- → P1
Whiteboard: [necko-triaged][trr]
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.
Assignee: daniel → nobody
Priority: P1 → P3
Whiteboard: [necko-triaged][trr] → [necko-triaged]
This is the #3 Windows topcrash in Nightly 20180216104033.
Keywords: topcrash
The GetHostToLookup signature spikes in nightly since February 16th.
Flags: needinfo?(daniel)
Assignee: nobody → daniel
Flags: needinfo?(daniel)
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.
Duplicate of this bug: 1439221
Whiteboard: [necko-triaged] → [necko-triaged][trr]
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.
Status: NEW → RESOLVED
Closed: 2 years ago
Depends on: 1439538
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.