我有一个带有大量JS脚本的Web应用程序（重要的是我的意思是很多客户端处理无法在服务器端完成）。
经过1小时左右（不是恒定的）处理后，我得到了Chrome的＆＃34; Aw，Snap！＆＃34; 错误，我已在https://superuser.com/questions/607563/how-to-determine-what-is-causing-chrome-to-show-the-aw-snap-dialogue中调整为建议我注意到每次收到错误时，日志都会提示WARNING:audio_sync_reader.cc(177)] ASR: No room in socket buffer.
我坚信我有点内存不足，因为如果我在这个错误之后打开其他标签，我会得到其他人＆＃34; Aw，Snap！＆＃34; 。
但是，考虑到我的JS脚本很长并且需要花费很长时间才能抛出错误，我如何识别哪一段代码正在引发错误呢？
PS：我也有很多DOM操作（主要是在表上插入）
谢谢！
答案 0 :(得分：0)
它不一定是某一行或一段代码。它只是你的应用程序消耗大量内存。这可能是由内存泄漏引起的，您可以通过查看调试器内存选项卡来识别内存泄漏。如果没有内存泄漏，您应该过度考虑代码结构。
答案 1 :(得分：0)
我有一个类似的问题：
[0225/064309.871791:WARNING:audio_sync_reader.cc(175)] ASR: No room in socket buffer.: Broken pipe (32)
我在Docker容器中以无头模式运行Chrome。上面的警告是由与Linux /dev/shm共享内存空间有关的另一个内存问题引起的。此页面对其进行了更详细的描述：
https://github.com/puppeteer/puppeteer/blob/master/docs/troubleshooting.md#tips
Docker仅为/dev/shm分配64MB。我认为Chrome使用/dev/shm存储由当前浏览器标签加载的图像（未压缩）。至少，这可以解释为什么只有网站包含一个或多个大图像时，Chrome才会失败。 ASR: No room in socket buffer.错误只是占用/dev/shm并占用较大图像的副作用。
使用--disable-dev-shm-usage Chrome命令行标志解决了此问题。