Closed Bug 1912551 Opened 3 months ago Closed 3 months ago

Crash in [@ mozilla::net::HttpBaseChannel::ShouldFilterOpaqueResponse] - MOZ_DIAGNOSTIC_ASSERT(ShouldBlockOpaqueResponse())

Categories

(Core :: DOM: Networking, defect, P2)

Other
All
defect

Tracking

()

RESOLVED FIXED
131 Branch
Tracking Status
firefox-esr115 --- wontfix
firefox-esr128 --- wontfix
firefox130 --- wontfix
firefox131 --- fixed

People

(Reporter: release-mgmt-account-bot, Assigned: farre)

References

(Blocks 1 open bug, Regression)

Details

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

Crash Data

Attachments

(1 file)

Crash report: https://crash-stats.mozilla.org/report/index/397badbd-ccf1-4a54-bf26-f63900240806

MOZ_CRASH Reason: MOZ_DIAGNOSTIC_ASSERT(ShouldBlockOpaqueResponse())

Top 10 frames of crashing thread:

0  libxul.so  mozilla::net::HttpBaseChannel::ShouldFilterOpaqueResponse const  netwerk/protocol/http/HttpBaseChannel.cpp:3165
1  libxul.so  mozilla::net::HttpBaseChannel::BlockOrFilterOpaqueResponse  netwerk/protocol/http/HttpBaseChannel.cpp:3269
2  libxul.so  mozilla::net::OpaqueResponseBlocker::EnsureOpaqueResponseIsAllowedAfterJavaScriptValidation  netwerk/protocol/http/OpaqueResponseUtils.cpp:465
2  libxul.so  mozilla::net::OpaqueResponseBlocker::ValidateJavaScript const  netwerk/protocol/http/OpaqueResponseUtils.cpp:554
2  libxul.so  std::_Function_handler<void   /builds/worker/fetches/sysroot-x86_64-linux-gnu/usr/include/c++/8/bits/std_function.h:297
3  libxul.so  std::function<void  const  /builds/worker/fetches/sysroot-x86_64-linux-gnu/usr/include/c++/8/bits/std_function.h:687
3  libxul.so  mozilla::dom::JSValidatorParent::IsOpaqueResponseAllowed const  dom/ipc/JSValidatorParent.cpp:40
3  libxul.so  mozilla::MozPromise<std::tuple<mozilla::Maybe<mozilla::ipc::Shmem>, mozilla::net::OpaqueResponseBlocker::ValidatorResult>, mozilla::ipc::ResponseRejectReason, true>::InvokeMethod<mozilla::dom::JSValidatorParent::IsOpaqueResponseAllowed  xpcom/threads/MozPromise.h:652
3  libxul.so  mozilla::MozPromise<std::tuple<mozilla::Maybe<mozilla::ipc::Shmem>, mozilla::net::OpaqueResponseBlocker::ValidatorResult>, mozilla::ipc::ResponseRejectReason, true>::InvokeCallbackMethod<false, mozilla::dom::JSValidatorParent::IsOpaqueResponseAllowed  xpcom/threads/MozPromise.h:683
3  libxul.so  mozilla::MozPromise<std::tuple<mozilla::Maybe<mozilla::ipc::Shmem>, mozilla::net::OpaqueResponseBlocker::ValidatorResult>, mozilla::ipc::ResponseRejectReason, true>::ThenValue<mozilla::dom::JSValidatorParent::IsOpaqueResponseAllowed  xpcom/threads/MozPromise.h:922

By querying Nightly crashes reported within the last 2 months, here are some insights about the signature:

  • First crash report: 2024-07-10
  • Process type: Parent
  • Is startup crash: No
  • Has user comments: No
  • Is null crash: Yes - 2 out of 4 crashes happened on null or near null memory address
Component: General → Networking: HTTP

ORB assertion
(all crashes are diagnostic assertions)

Component: Networking: HTTP → DOM: Networking
Flags: needinfo?(afarre)
Summary: Crash in [@ mozilla::net::HttpBaseChannel::ShouldFilterOpaqueResponse] → Crash in [@ mozilla::net::HttpBaseChannel::ShouldFilterOpaqueResponse] - MOZ_DIAGNOSTIC_ASSERT(ShouldBlockOpaqueResponse())

So this is most likely that a tab is going away or a full browser close that happens when we're waiting for the result of the JSValidator (all crashes are diagnostic asserts when getting back a result from the validator). Maybe this assert is a bit too strict, if we've closed the tab or navigated away this should be canceled in any case. So let's downgrade the assert to a MOZ_ASSERT, that way if it shows up on try we'll at least now what triggered it.

But I guess if it isn't that e.g. the load info not being there, then the reason are one of:

  • The content policy has changed
  • The security mode has changed
  • The tainting has changed
  • The external content policy has changed
  • The response suddenly transformed to an object or embed
  • The https only status changed
  • DevTools has started

If any of these have changed since we initiated the load, we still started the load with what ShouldBlockOpaqueResponse saw, and it really doesn't matter what ShouldBlockOpaqueResponse is in that case. So it might be that we should remove the assert entirely. But let's keep it in debug builds for now.

Sean, does this sound sane?

Try run is here, patch following.

Assignee: nobody → afarre
Status: NEW → ASSIGNED
Flags: needinfo?(afarre) → needinfo?(sefeng)

In the case where the js validator comes back with a result and

Yeah, sounds sane

Flags: needinfo?(sefeng)
Severity: -- → S3
Priority: -- → P2
Whiteboard: [necko-triaged]
Pushed by afarre@mozilla.com: https://hg.mozilla.org/integration/autoland/rev/87b2cc00563f Adjust invariant checking to only happen in debug builds. r=sefeng,necko-reviewers
Status: ASSIGNED → RESOLVED
Closed: 3 months ago
Resolution: --- → FIXED
Target Milestone: --- → 131 Branch
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: