Issue metadata
Sign in to add a comment
|
Unbounded browser process memory growth due to WebSocket SafeBrowsing checks |
||||||||||||||||||||
Issue description
You can cause the browser process to keep allocating memory by creating WebSockets in a loop like this:
while (true) {
new WebSocket('ws://128.0.0.0');
}
This is basically a repeat of issue 459377, this time caused by the browser-side SafeBrowsing code allocating memory for every lookup.
The memory growth of the render process is faster than that of the browser process, so generally the render process will crash first, freeing the browser-side memory.
Still, it would be good to fix. Probably some kind of throttling would be appropriate.
,
Sep 13 2017
When is the std::unique_ptr<blink::WebSocketHandshakeThrottle> for each websocket instance gets destroyed? Some browser-side state will only be cleared after this object (more specifically, the mojom::SafeBrowsingUrlCheckerPtr member of this object) is reset or destroyed.
,
Sep 13 2017
,
Sep 14 2017
std::unique_ptr<blink::WebSocketHandshakeThrottle> will be destroyed once we receive a response. I ran a modified version of the test where I periodically return to the event loop (with setTimeout) and it doesn't exhibit unbounded growth. So I think the problem is that the responses are never processed by the renderer. I plan to address the problem by limiting the number of outstanding mojo requests to 64, and queuing inside the render process after that. While this is simple in principle, it will probably double the amount of code in practice.
,
Sep 4
Still happens. It's a very slow and boring DoS. |
|||||||||||||||||||||
►
Sign in to add a comment |
|||||||||||||||||||||
Comment 1 by ricea@chromium.org
, Sep 13 201771 bytes
71 bytes View Download