I have a web application with heavy JS scripts (by heavy I mean lots of client processing which can’t be done on the server side).
After 1 hour or so (not constant) of processing I get Chrome’s “Aw, Snap!” error, I have debugged as suggest in https://superuser.com/questions/607563/how-to-determine-what-is-causing-chrome-to-show-the-aw-snap-dialogue and I noticed that everytime I get the error, the log is prompting
WARNING:audio_sync_reader.cc(177)] ASR: No room in socket buffer.
I strongly believe that I am kind of running out of memory, because if I open other tabs after this error I get others “Aw, Snap!”.
However, considering that my JS script is long and it takes a long time to throw the error, how can I identify which piece of code is raising it?
PS.: I also have many DOM manipulations (mainly insertions on a table)
Its not necessarily a certain line or a block of code. Its just that your application consumes to much memory. That can be caused by a a memory leak, which you can identify by looking at the debuggers memory tab. If no memory is leaking you should overthink your codes structure.
I had a similar issue:
[0225/064309.871791:WARNING:audio_sync_reader.cc(175)] ASR: No room in socket buffer.: Broken pipe (32)
I was running Chrome in headless mode in a Docker container. The warning above was caused by another memory issue related to the
/dev/shm shared memory space of Linux. This page describes it in more detail:
Docker only allocates 64MB for
/dev/shm. I suppose that Chrome use
/dev/shm to store images (uncompressed) which are loaded by the current browser tab. At least this would explain why Chrome only failed, when the website contained one or more large images. The
ASR: No room in socket buffer. error was only a side-effect of occupying
/dev/shm with the large images.
--disable-dev-shm-usage Chrome command line flag solved this issue.