Closed Bug 1675207 Opened 4 years ago Closed 3 years ago

Crash in [@ OOM | large | NS_ABORT_OOM | nsTSubstring<T>::Append | mozilla::net::WebSocketChannelChild::RecvOnMessageAvailableInternal]

Categories

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

x86
Unspecified
defect

Tracking

()

RESOLVED FIXED
86 Branch
Tracking Status
firefox-esr78 --- unaffected
firefox82 --- wontfix
firefox83 --- wontfix
firefox84 --- wontfix
firefox85 --- wontfix
firefox86 --- fixed

People

(Reporter: aryx, Assigned: kershaw)

References

Details

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

Crash Data

Attachments

(1 file)

Low volume, affects Firefox 82+, code got changed in bug 1660361 for Firefox 82.

Crash report: https://crash-stats.mozilla.org/report/index/c001fced-4901-4dcf-888a-a38380201104

MOZ_CRASH Reason: MOZ_CRASH(OOM)

Top 10 frames of crashing thread:

0 xul.dll NS_ABORT_OOM xpcom/base/nsDebugImpl.cpp:618
1 xul.dll nsTSubstring<char>::Append xpcom/string/nsTSubstring.cpp:830
2 xul.dll mozilla::net::WebSocketChannelChild::RecvOnMessageAvailableInternal netwerk/protocol/websocket/WebSocketChannelChild.cpp:298
3 xul.dll mozilla::net::WebSocketChannelChild::RecvOnMessageAvailable netwerk/protocol/websocket/WebSocketChannelChild.cpp:312
4 xul.dll mozilla::net::PWebSocketChild::OnMessageReceived ipc/ipdl/PWebSocketChild.cpp:416
5 xul.dll mozilla::dom::PContentChild::OnMessageReceived ipc/ipdl/PContentChild.cpp:8579
6 xul.dll mozilla::ipc::MessageChannel::DispatchMessage ipc/glue/MessageChannel.cpp:2074
7 xul.dll mozilla::ipc::MessageChannel::MessageTask::Run ipc/glue/MessageChannel.cpp:1953
8 xul.dll mozilla::SchedulerGroup::Runnable::Run xpcom/threads/SchedulerGroup.cpp:146
9 xul.dll mozilla::TaskController::DoExecuteNextTaskOnlyMainThreadInternal xpcom/threads/TaskController.cpp:515
Flags: needinfo?(kershaw)

Well, after bug 1660361 the crash MOZ_CRASH("IPC message size is too large") in parent process is gone, but we got OOM crashes in child processes. I think crash in child process is a little bit better than parent process, so I think we should not revert the changes done in bug 1660361.
To fix this kind of issue once for all, we should move the logic in WebSocketChannel::ProcessInput to child process.

Assignee: nobody → kershaw
Severity: -- → S3
Flags: needinfo?(kershaw)
Priority: -- → P2
Whiteboard: [necko-triaged]
Pushed by kjang@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/259ad0fe9f08
Fail the websocket connection when there is no enough memory r=necko-reviewers,valentin
Pushed by kjang@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/084279c12a76
Fail the websocket connection when there is no enough memory r=necko-reviewers,valentin
Pushed by kjang@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/1068ecdf3b83
Fail the websocket connection when there is no enough memory r=necko-reviewers,valentin
Backout by archaeopteryx@coole-files.de:
https://hg.mozilla.org/mozilla-central/rev/4f9d4fa5a2ba
Backed out changeset 084279c12a76 for build bustage complaining about rules.mk. CLOSED TREE
Pushed by cbrindusan@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/e291934f11cc
Fail the websocket connection when there is no enough memory r=necko-reviewers,valentin CLOSED TREE
Status: NEW → RESOLVED
Closed: 3 years ago
Resolution: --- → FIXED
Target Milestone: --- → 86 Branch

Since the status are different for nightly and release, what's the status for beta?
For more information, please visit auto_nag documentation.

The patch landed in nightly and beta is affected.
:kershaw, is this bug important enough to require an uplift?
If not please set status_beta to wontfix.

For more information, please visit auto_nag documentation.

Flags: needinfo?(kershaw)

This is an OOM, so I think we don't need to uplift this.

Flags: needinfo?(kershaw)
Regressions: 1683847
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: