Crash in [@ mozilla::net::AltSvcMapping::Release]
Categories
(Core :: XPCOM, defect)
Tracking
()
Tracking | Status | |
---|---|---|
firefox-esr102 | --- | unaffected |
firefox111 | --- | wontfix |
firefox112 | - | wontfix |
firefox113 | --- | affected |
People
(Reporter: aryx, Unassigned)
References
Details
(Keywords: crash)
Crash Data
5-15 crashes for 112.0b beta version, 111.0b had 0-1 crash per version with one exception. All on Windows.
Crash report: https://crash-stats.mozilla.org/report/index/437c094b-39ae-4800-a125-e99120230323
Reason: EXCEPTION_BREAKPOINT
Top 10 frames of crashing thread:
0 xul.dll mozilla::MozPromise<bool, nsresult, 1>::ThenValueBase::AssertIsDead xpcom/threads/MozPromise.h:526
1 xul.dll mozilla::MozPromise<bool, nsresult, 1>::AssertIsDead xpcom/threads/MozPromise.h:1119
2 xul.dll mozilla::MozPromise<bool, nsresult, 1>::~MozPromise xpcom/threads/MozPromise.h:1162
3 xul.dll mozilla::MozPromise<bool, nsresult, 1>::Private::~Private xpcom/threads/MozPromise.h:256
4 xul.dll mozilla::net::AltSvcMapping::Release netwerk/protocol/http/AlternateServices.h:47
4 xul.dll mozilla::RefPtrTraits<mozilla::net::AltSvcMapping>::Release mfbt/RefPtr.h:50
4 xul.dll RefPtr<mozilla::net::AltSvcMapping>::ConstRemovingRefPtrTraits<mozilla::net::AltSvcMapping>::Release mfbt/RefPtr.h:381
4 xul.dll RefPtr<mozilla::net::AltSvcMapping>::~RefPtr mfbt/RefPtr.h:81
4 xul.dll mozilla::net::AltSvcMappingValidator::~AltSvcMappingValidator netwerk/protocol/http/AlternateServices.h:228
4 xul.dll mozilla::net::AltSvcMappingValidator::~AltSvcMappingValidator netwerk/protocol/http/AlternateServices.h:228
Updated•2 years ago
|
Comment 1•2 years ago
|
||
I think this is a XPCOM bug, since the MozPromise
is used in TaskQueue.
The reason that we saw AltSvcMapping
in the stack is that AltSvcMapping holds a pointer to DataStorage, and DataStorage
uses TaskQueue
here.
Comment 2•2 years ago
|
||
The bug is marked as tracked for firefox112 (beta). We have limited time to fix this, the soft freeze is in 13 days. However, the bug still isn't assigned.
:gcp, could you please find an assignee for this tracked bug? If you disagree with the tracking decision, please talk with the release managers.
For more information, please visit auto_nag documentation.
Comment 3•2 years ago
|
||
(In reply to Release mgmt bot [:suhaib / :marco/ :calixte] from comment #2)
The bug is marked as tracked for firefox112 (beta). We have limited time to fix this, the soft freeze is in 13 days. However, the bug still isn't assigned.
:gcp, could you please find an assignee for this tracked bug? If you disagree with the tracking decision, please talk with the release managers.
For more information, please visit auto_nag documentation.
This bug is not new but the result of a signature de-mangling, I would suggest to not track it as new regression.
Updated•2 years ago
|
Comment 4•2 years ago
|
||
The severity field is not set for this bug.
:nika, could you have a look please?
For more information, please visit auto_nag documentation.
Comment 5•2 years ago
|
||
Seems to have stopped since 112b7? Perhaps the signature changed again.
I don't know the exact cause here, it's unfortunately a bit tricky to tell. In this case, the issue appears to be that a MozPromise
was destroyed without being resolved.
I've filed bug 1827281 to try to improve our tracking of what we're waiting on in situations like this going forward.
Updated•2 years ago
|
Description
•