This bug was filed from the Socorro interface and is report bp-8ce355b6-ea89-4869-b299-0850a0181120. ============================================================= This is a top crash for Fennec on release. Not sure if it should go in Firefox for Android component or in Networking::Websockets. Filed as a followup from bug 1498194. Top 10 frames of crashing thread: 0 libxul.so NS_ABORT_OOM xpcom/base/nsDebugImpl.cpp:628 1 libxul.so nsTSubstring<char16_t>::SetLength xpcom/string/nsTSubstring.cpp:847 2 libxul.so IPC::ParamTraits<nsTSubstring<char16_t> >::Read ipc/glue/IPCMessageUtils.h:462 3 libxul.so mozilla::net::WebSocketFrameRunnable::~WebSocketFrameRunnable netwerk/protocol/websocket/WebSocketEventService.cpp:70 4 libxul.so mozilla::dom::PBackgroundStorageParent::OnMessageReceived ipc/ipdl/PBackgroundStorageParent.cpp:461 5 libmozglue.so RedBlackTree<arena_chunk_map_t, ArenaAvailTreeTrait>::MoveRedRight 6 libmozglue.so RedBlackTree<arena_chunk_map_t, ArenaAvailTreeTrait>::MoveRedLeft 7 libc.so libc.so@0x4943a 8 libxul.so mbrtoc32 9 libxul.so mbrtoc32 =============================================================

WebSocketFrameRunnable is created only in WebSocketEventService::FrameReceived() and WebSocketEventService::FrameSent() if there is any nsIWebSocketEventListener registered at the service. I couldn't find any code using this service. Honza, am I right that devtools doesn't use nsIWebSocketEventService at all? If so, it seems that the call stack isn't correct.

I am not entirely sure. DevTools are using WebSockets e.g. for debugger transport layer. @Alex, I am thinking about this code: https://searchfox.org/mozilla-central/source/devtools/shared/security/socket.js#682 Are there any WebSockets listeners involved? Or any other parts of DevTools could be involved? Honza

(In reply to Jan Honza Odvarko [:Honza] (need-info? me) from comment #2) > I am not entirely sure. DevTools are using WebSockets e.g. for debugger > transport layer. > > @Alex, I am thinking about this code: > https://searchfox.org/mozilla-central/source/devtools/shared/security/socket. > js#682 Sorry about the delay!! WebSockets shouldn't be used anywhere for DevTools protocol. The DevTools server do support WebSocket, but that is an optional feature, that I believe is only used optionally by contributors using launchpad to run our tools. See this doc: https://firefox-dev.tools/debugger.html/docs/getting-setup.html#firefox-using-websocket-transport On android, we are using a unix domain socket to communicate through ADB: https://searchfox.org/mozilla-central/source/mobile/android/app/mobile.js#369-371 https://searchfox.org/mozilla-central/source/mobile/android/chrome/content/RemoteDebugger.js#273-283 Same thing for geckoview: https://searchfox.org/mozilla-central/source/mobile/android/modules/geckoview/GeckoViewRemoteDebugger.jsm#72-85 Now, some people for some unexpected reason may try to enable websocket devtools server on android (via custom preferences), but that would be only a couple of people doing unexpected/undocumented things! Otherwise, we are not using nsIWebSocketEventService anywhere in DevTools. We are using WebSocket.createServerWebSocket: https://searchfox.org/mozilla-central/source/dom/webidl/WebSocket.webidl#71-77 https://searchfox.org/mozilla-central/source/devtools/server/socket/websocket-server.js#208 But again, that's related to the optional feature I just described, which isn't used by default and it seems very unlikely that anyone is using it on Android.

P1 given the high crash rate on fennec

Alexandre, my original question was about using WebSocketEventService not WebSocket server/client. WebSocketEventService notifies registered listeners about all sent/received messages by WebSocket connections associated with a given window. It was created for devtools so the developers can see all WebSocket traffic in the network panel. But it looks like this functionality was never implemented in network panel and I couldn't use any other code using WebSocketEventService.

It was used by an old privileged add-on: https://github.com/firebug/websocket-monitor/blob/014afce40ea280eafae2cbd8d676ab9ec914bc8c/lib/wsm-actor.js#L61-L80 But as we deprecated all these add-ons in favor of WebExtension, this is no longer used. We never backported this add-on into DevTools, nor exposed this API through WebExtension. Honza may better know about eventual plan to implement this feature into Firefox again.

(In reply to Alexandre Poirot [:ochameau] from comment #6) > But as we deprecated all these add-ons in favor of WebExtension, this is no > longer used. > We never backported this add-on into DevTools, nor exposed this API through > WebExtension. > Honza may better know about eventual plan to implement this feature into > Firefox again. Yes, this is correct. The WebSocketMonitor extension isn't ported into the world of WebExtensions yet, but it's been requited by users many times and we definitely plan to do it at some point. It'll be based on the same service + new WebExtension API that expose it. Honza

Honza Bambas pointed out that frame 3 is invalid (probably shared code due to optimization) and important is frame 4. The message originates at https://searchfox.org/mozilla-central/rev/f2028b4c38bff2a50ed6aa1763f6dc5ee62b0cc4/dom/storage/StorageIPC.cpp#324. Jan, I think you're familiar with that code. Can you have a look?

This problem has been described in bug 1475218 comment 9. New localStorage implementation should land following days, however preffed-off for now. We plan to enable it in next cycle (FF 66). We'll see if it helps to lower down number of crashes related to this problem.

Per comment 9, looks like DOM: Web Storage may be a better fit.