Crash in [@ mozilla::net::DnsAndConnectSocket::TransportSetup::SetupStreams]
Categories
(Core :: Networking: HTTP, defect, P1)
Tracking
()
Tracking | Status | |
---|---|---|
firefox-esr78 | --- | unaffected |
firefox88 | --- | unaffected |
firefox89 | --- | unaffected |
firefox90 | --- | unaffected |
firefox91 | + | fixed |
People
(Reporter: aryx, Assigned: dragana)
References
(Regression)
Details
(Keywords: crash, regression, Whiteboard: [necko-triaged])
Crash Data
Attachments
(3 files)
13 crashes with 9 installations, all OS
Crash report: https://crash-stats.mozilla.org/report/index/a7a05ac8-4146-40d1-9790-0da350210518
MOZ_CRASH Reason: MOZ_DIAGNOSTIC_ASSERT(ent)
Top 10 frames of crashing thread:
0 xul.dll mozilla::net::DnsAndConnectSocket::TransportSetup::SetupStreams netwerk/protocol/http/DnsAndConnectSocket.cpp:1176
1 xul.dll mozilla::net::DnsAndConnectSocket::TransportSetup::OnLookupComplete netwerk/protocol/http/DnsAndConnectSocket.cpp:1249
2 xul.dll mozilla::net::DnsAndConnectSocket::OnLookupComplete netwerk/protocol/http/DnsAndConnectSocket.cpp:419
3 xul.dll mozilla::detail::RunnableFunction<`lambda at /builds/worker/checkouts/gecko/netwerk/dns/DNSListenerProxy.cpp:28:30'>::Run xpcom/threads/nsThreadUtils.h:534
4 xul.dll nsThread::ProcessNextEvent xpcom/threads/nsThread.cpp:1153
5 xul.dll mozilla::net::nsSocketTransportService::Run netwerk/base/nsSocketTransportService2.cpp:1200
6 xul.dll nsThread::ProcessNextEvent xpcom/threads/nsThread.cpp:1153
7 xul.dll mozilla::ipc::MessagePumpForNonMainThreads::Run ipc/glue/MessagePump.cpp:300
8 xul.dll MessageLoop::RunHandler ipc/chromium/src/base/message_loop.cc:328
9 xul.dll MessageLoop::Run ipc/chromium/src/base/message_loop.cc:310
Assignee | ||
Updated•3 years ago
|
Assignee | ||
Comment 1•3 years ago
|
||
Assignee | ||
Updated•3 years ago
|
Assignee | ||
Comment 2•3 years ago
|
||
Assignee | ||
Comment 3•3 years ago
|
||
Bug 1705065 was backed out, so 90 is no affected any more.
Updated•3 years ago
|
Updated•3 years ago
|
Comment 5•3 years ago
|
||
bugherder |
Reporter | ||
Comment 6•3 years ago
|
||
So far 5 assertion failures hitting this in the latest Nightly, e.g. bp-5223a070-9a20-45cc-a79c-d9fd40210610
Assignee | ||
Comment 7•3 years ago
|
||
Thanks to the new asserts, We have more information what is happening. I think I can fix this issue. I will work on patch today.
Comment 8•3 years ago
|
||
Can we at least disable the diagnostic asserts asap?
Assignee | ||
Comment 9•3 years ago
|
||
Assignee | ||
Comment 10•3 years ago
|
||
Assignee | ||
Comment 11•3 years ago
|
||
(In reply to Julien Cristau [:jcristau] from comment #8)
Can we at least disable the diagnostic asserts asap?
I will try to resolve the issues as soon as possible.
There are 2 kind of crashes:
- most common one should be resolved by D117706
- the other kind of crash is:
a988968b-91c0-4601-a3ad-9acff0210614
I am not sure how it is getting to that state. I will add more assertions to figure it out.
Comment 12•3 years ago
|
||
Comment 13•3 years ago
|
||
Updated•3 years ago
|
Comment 14•3 years ago
|
||
bugherder |
Assignee | ||
Comment 15•3 years ago
|
||
Comment on attachment 9226936 [details]
When retrying to resolve a host always set the state to TransportSetupState::RETRY_RESOLVING. When a connection fails the status was set to TransportSetupState::RESOLVING which have a bad influence on the state of DnsAndConnectSocket.
Beta/Release Uplift Approval Request
- User impact if declined: Diagnostic asserts added in bug 1705065 showed that DnsAndConnectSocket is sometimes in a wrong state. This patch has fix that. The effect on users is unclear. This may help with crash in 1667102, but I do not have a real good explanation how it would help.
- Is this code covered by automated tests?: Yes
- Has the fix been verified in Nightly?: Yes
- Needs manual test from QE?: No
- If yes, steps to reproduce:
- List of other uplifts needed: None
- Risk to taking this patch: Low
- Why is the change risky/not risky? (and alternatives if risky): Fixes DnsAndConnectSocket state machine. And fix is verified in Nightly with a lot of diagnostic asserts that make sure that DnsAndConnectSocket is in a proper state.
- String changes made/needed:
Updated•3 years ago
|
Comment 16•3 years ago
|
||
Given the low (known) impact, and given we're in the last week for beta 90, I'd prefer to let this ride the trains.
Updated•3 years ago
|
Comment 17•3 years ago
|
||
Should this be marked as fixed now, or is there more work to do? (the leave-open keyword is still around from the first diagnostic patch)
Assignee | ||
Comment 18•3 years ago
|
||
I was waiting a bit to be sure there is no other issue.
This can be closed now.
Updated•3 years ago
|
Updated•3 years ago
|
Description
•