Other related issues I found (but they seem to have been closed already):

https://bugs.chromium.org/p/chromium/issues/detail?id=138506
https://bugs.chromium.org/p/chromium/issues/detail?id=599028 (mentioned above)
https://bugs.chromium.org/p/chromium/issues/detail?id=235796 (<- archived; this seems like the same exact bug, but wasn't re-opened?)

Hopefully the trace info I provided helps fix this quickly? If there's more debugging you'd like me to do I can try to e.g. get a GDB backtrace or the like.

I agree it should definitely NOT be possible to crash the BROWSER process like this. A  Thanks for the report!  It sounds like we're hitting a max-size check in mojo at https://cs.chromium.org/chromium/src/mojo/edk/system/node_channel.cc?type=cs&q=%22message-%3Edata_num_bytes()+%3C+GetConfiguration().max_message_num_bytes%22&sq=package:chromium&l=895, so this is likely a new problem (the previous crashes don't sound like browser crashes).

At a minimum we should be doing the same check in the renderer and gracefully failing the XHR.  Better, of course, is to remove the restriction (eg. by chunking the data or using shared memory or whatever).

tyoshino WDYT?

 

Yeah, my guess might be the difference from previous bugs is my os/arch, and the behavior that crashes their tabs crashes my browser instead. Since I'm on Arch Linux, it's possible that this doesn't even affect say, Ubuntu, in which case it might not be high-priority, but should still be in the system :)

I failed to reproduce the issue (I used a 500MB file).

pmawhorter@, can you share your script? You don't have to upload the big file unless the issue depends on the file content.

Deleted: index.html 289 bytes

index.html 289 bytes View Download

Here's a version (you'll have to modify big_file_url) that (tries to) load the file 10000 times. For me this reproducibly crashes an individual window "Oh Snap" when loaded in a freshly-opened browser without any other pages active. If I've got gmail open in another tab, it crashes the whole browser instead. Must be a process-wide limit being hit somewhere? Just loading a single file in an otherwise idle browser didn't do it for me, as you confirmed, so it's likely not dependent on the individual file size.

Deleted: index.html 530 bytes

index.html 530 bytes View Download

Thank you for providing more feedback. Adding requester "yhirano@chromium.org" to the cc list and removing "Needs-Feedback" label.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

Note: The syncrhonous setting on the XHR in that last example shouldn't be necessary; I added that because my original code had it and I thought that that alone might make the difference but it didn't (yes, I know my code shouldn't be using synchronous XHR in the first place :P).

I suspect it's the string conversion causing the OOM. Assigning to myself to confirm later.

#7 This tries to allocate 200M * 10000 = 2TB of memory, which isn't going to work unless your computer is a lot better than mine. Usually the render process crashes with an out-of-memory error, but sometimes the OS will run out of memory and kill another process instead.

If I remove the "mem" array then it doesn't run out of memory, and nothing crashes. If I leave devtools open then it does run out of memory as devtools causes the responses to be retained in memory.

That makes sense, and I understand there may not be a reliable way of catching these memory errors and reporting them as exceptions within JS. The note about devtools may have been the root of my initial problems then, because I certainly wasn't loading enough in a single run of the page to use up my computer's memory, but I *was* debugging at the time, so I may have had the devtools open through multiple iterations of the page loading?

I don't have time right now but I'll try to reproduce without using up OS memory, since I think I recall triggering the browser crash by having something like gmail + youtube open and then trying to load just a single ~200MB file.

Marking as WontFix due to inactivity.