Closed Bug 1438904 Opened 2 years ago Closed 2 years ago
Crash in ns
Host Resolver::Get Host To Lookup
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  to fix bug 1434852.  https://hg.mozilla.org/mozilla-central/rev?node=6776d69d2f03
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
Priority: -- → P1
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.
The GetHostToLookup signature spikes in nightly since February 16th.
Assignee: nobody → 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.
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.