Closed Bug 795534 Opened 13 years ago Closed 10 years ago

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

Categories

(Core :: DOM: Core & HTML, defect)

Product:
Core
Component:
DOM: Core & HTML
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

()

Status:
RESOLVED WORKSFORME
Tracking Flags:
Tracking Status
b2g-v2.5 --- fixed

People

(Reporter: seth, Unassigned)

References

Details

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.
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
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.
Actually I have now confirmed that the error console issue needs a separate bug, which I've filed as bug 796179.
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.
CC'ing bsmedberg to bring in more electrolysis expertise.
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.
This issue no longer manifests on Android or e10s.
Status: NEW → RESOLVED
Closed: 10 years ago
Flags: in-testsuite+
Resolution: --- → WORKSFORME
Component: DOM → DOM: Core & HTML
You need to log in before you can comment on or make changes to this bug.