Crash in IPCError-browser | SHMEM_CREATED_MESSAGE Payload error: message could not be deserialized
Categories
(Core :: DOM: Copy & Paste and Drag & Drop, defect, P3)
Tracking
()
People
(Reporter: ananuti, Unassigned)
Details
(Keywords: crash, Whiteboard: [MemShrink:P3])
Crash Data
This bug was filed from the Socorro interface and is report bp-465f71ba-d8f0-4a45-988c-81e600180705. ============================================================= Top 10 frames of crashing thread: 0 ntdll.dll KiFastSystemCallRet 1 ntdll.dll NtAllocateVirtualMemory 2 kernelbase.dll VirtualAllocExNuma 3 kernelbase.dll VirtualAllocEx 4 xul.dll mozilla::VolatileBuffer::Lock memory/volatile/VolatileBufferWindows.cpp:105 5 xul.dll mozilla::VolatileBufferPtr_base::Lock memory/volatile/VolatileBuffer.h:122 6 xul.dll mozilla::gfx::SourceSurfaceVolatileData::Map gfx/layers/SourceSurfaceVolatileData.h:76 7 xul.dll mozilla::gfx::DataSourceSurface::ScopedMap::ScopedMap gfx/2d/2D.h:479 8 xul.dll mozilla::Maybe<mozilla::gfx::DataSourceSurface::ScopedMap>::emplace<RefPtr<mozilla::gfx::DataSourceSurface>&, mozilla::gfx::DataSourceSurface::MapType> mfbt/Maybe.h:599 9 xul.dll mozilla::image::DrawableFrameRef::DrawableFrameRef image/imgFrame.h:346 ============================================================= Drag the image https://upload.wikimedia.org/wikipedia/commons/3/3d/LARGE_elevation.jpg and drop onto desktop.
Comment 1•6 years ago
|
||
I don't understand why the signature was replaced with an IPC error like that — the stack looks like graphics trying and failing to allocate memory internally, and I don't see any references to IPC anywhere else in the crash report (except MessageLoop, which isn't specific to actual IPC as I understand it). If I had to guess the cause I'd assume address space exhaustion (32-bit build, large image, “NtAllocateVirtualMemory”), which might also be connected to problems with allocating space to map shared memory.
Updated•6 years ago
|
Updated•6 years ago
|
Comment 2•3 years ago
|
||
I hit this crash when trying to take a page screenshot of https://protosaur.dev/fission-experiment-monitoring-dashboard/dashboard/dashboard.html.
Comment 3•3 years ago
|
||
I think I know what's going on here: it's a paired minidump. (The only indication of this seems to be the additional_minidumps
key in the Crash Annotations tab, which is… not great UI.) Specifically: the parent process fails to deserialize a SHMEM_CREATED_MESSAGE
, sets the annotation, then interrupts the child process in the middle of some random other thing to kill it and create a crash report of that unhelpful state. I assume there's a corresponding parent process crash report buried in the DB somewhere, but that's also not very helpful, because I can probably tell you the stack just by looking at the source; it won't even tell me where in deserialization it failed.
That said, we will “fail to deserialize” a ShmemCreated
if we fail to map the memory. So, despite working from bad data in comment #1, I ended up in roughly the right place: this is mostly likely due to address space exhaustion.
Comment 4•2 years ago
|
||
I hit this content crash again in Nightly 106. I crashed twice when trying to load a Google Doc. Probably an OOM since I have many Google Docs open and I'm running 32-bit Firefox.
bp-d2273412-d017-4660-815c-f011f0220831
bp-6b748a2c-d1ac-469b-9887-4893f0220831
Comment 5•2 years ago
|
||
Since the crash volume is low (less than 5 per week), the severity is downgraded to S3
. Feel free to change it back if you think the bug is still critical.
For more information, please visit auto_nag documentation.
Comment 6•20 days ago
|
||
Closing because no crashes reported for 12 weeks.
Description
•