Open Bug 1824150 Opened 2 years ago Updated 2 years ago

Crash in [@ mozilla::net::AltSvcMapping::Release]

Categories

(Core :: XPCOM, defect)

Unspecified
Windows
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
Depends on: 1635953

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.

Component: Networking: HTTP → XPCOM

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.

Flags: needinfo?(gpascutto)

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

Flags: needinfo?(dsmith)
Flags: needinfo?(gpascutto)
See Also: → 1824299

The severity field is not set for this bug.
:nika, could you have a look please?

For more information, please visit auto_nag documentation.

Flags: needinfo?(nika)

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.

Severity: -- → S3
Flags: needinfo?(nika)
You need to log in before you can comment on or make changes to this bug.