If you think a bug might affect users in the 57 release, please set the correct tracking and status flags for Release Management.

Sending large numbers of errors to the error console can consume a huge amount of memory with IPC enabled

RESOLVED WORKSFORME

Status

()

Core
DOM
RESOLVED WORKSFORME
5 years ago
2 years ago

People

(Reporter: seth, Unassigned)

Tracking

Trunk
Points:
---
Bug Flags:
in-testsuite +

Firefox Tracking Flags

(b2g-v2.5 fixed)

Details

(Reporter)

Description

5 years ago
In testing the fix for bug 786108, I observed that sending large numbers of large error messages to the error console could easily consume gigabytes of memory in no time with IPC enabled, while without IPC enabled a low and stable amount of memory is consumed.

https://bugzilla.mozilla.org/attachment.cgi?id=655822 demonstrates the problem, as do the crashtests found in the patch for bug 786108.
(Reporter)

Comment 1

5 years ago
Haven't had a chance to investigate further yet.
The underlying problem here is that string-ifying the messages can consume an unbounded amount of memory.  It is true that the IPC console is especially dumb, but I strongly suggest the "real fix" be to limit the size of the messages.

Fixing up the dumbness in the IPC console implementation is partly covered by bug 794599.
(Not sure where the error console component is, but Core:IPC is for issues related to the core IPC system itself.  Console is a consumer.)
Component: IPC → DOM
(Reporter)

Comment 4

5 years ago
I had been about to create a separate bug for the error console issue but if you suspect they are the same under the hood then that saves me the effort; thanks!

I'm not sure whether I agree that the right thing is to limit the size of the messages - it seems that has potential to do things like break the clickability of URLs in the error console. I don't understand the low level issues involved here, though.
(Reporter)

Comment 5

5 years ago
Actually I have now confirmed that the error console issue needs a separate bug, which I've filed as bug 796179.
(Reporter)

Comment 6

5 years ago
The IPC problem comes down to serialization breaking the string sharing that makes this cheap on the non-IPC build of Firefox. One could imagine trying to preserve string sharing relationships over IPC, but it seems quite nontrivial using the messaging model we have right now.

Another possible approach that seems like it might be simpler to implement would be to only send over abbreviated URIs like those displayed to the user in bug 796179. If the user clicks on an entry in the error console and the full URI is needed, it can either be requested via IPC or the process of loading the appropriate document can itself be delegated to the plugin process via IPC, whichever makes more sense. In either case, what we need is some sort of "key" that can be used to look up the full URI. The key itself would have to be cheap to send over IPC. If there's some sort of easily serializable document identifier, that could potentially work.
(Reporter)

Comment 7

5 years ago
CC'ing bsmedberg to bring in more electrolysis expertise.

Comment 8

5 years ago
I have no good input here: for B2G we should probably just fix the bug to disable the console by default and only turn it on in developer mode.

Updated

4 years ago
Duplicate of this bug: 881191
This issue no longer manifests on Android or e10s.
Status: NEW → RESOLVED
Last Resolved: 2 years ago
Flags: in-testsuite+
Resolution: --- → WORKSFORME

Comment 11

2 years ago
https://hg.mozilla.org/integration/mozilla-inbound/rev/9f2f0fa535f7

Comment 12

2 years ago
bugherder
https://hg.mozilla.org/mozilla-central/rev/9f2f0fa535f7

Comment 13

2 years ago
bugherderuplift
https://hg.mozilla.org/releases/mozilla-b2g44_v2_5/rev/9f2f0fa535f7
status-b2g-v2.5: --- → fixed
You need to log in before you can comment on or make changes to this bug.