Yes, while this is not immediately apparent what you're seeing here is an increase in OOM crashes and Fission users might be affected. >95% of the crashes here are coming from 32-bit users where the crashed process seem to have run out of virtual address space. That explains the lack of symbols in libxul. On 32-bit builds we set aside a chunk of virtual memory for Breakpad which we release upon hitting a crash, hoping that it's enough to let dbghelp.dll do its job while writing the minidump. In these cases apparently it's not. I don't think there's anything actionable here, most of the crashes are on 32-bit capable OSes so while the underlying hardware seem to support 64-bit operation the users wouldn't even be able to switch to a 64-bit build because of the OS.
Bug 1667476 Comment 7 Edit History
Note: The actual edited comment in the bug view page will always show the original commenter’s name and original timestamp.
Yes, while this is not immediately apparent what you're seeing here is an increase in OOM crashes and Fission users might be affected. >95% of the crashes here are coming from 32-bit users were the crashed process seem to have run out of virtual address space. That explains the lack of symbols in libxul. On 32-bit builds we set aside a chunk of virtual memory for Breakpad which we release upon hitting a crash, hoping that it's enough to let dbghelp.dll do its job while writing the minidump. In these cases apparently it's not. I don't think there's anything actionable here, most of the crashes are on 32-bit capable OSes so while the underlying hardware seem to support 64-bit operation the users wouldn't even be able to switch to a 64-bit build because of the OS.