Open Bug 1473564 Opened 4 years ago Updated 8 months ago

Crash in IPCError-browser | SHMEM_CREATED_MESSAGE Payload error: message could not be deserialized


(Core :: DOM: Copy & Paste and Drag & Drop, defect, P3)

63 Branch
Windows 10



Tracking Status
firefox63 --- affected
firefox88 --- affected


(Reporter: ananuti, Unassigned)


(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 and drop onto desktop.
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.
Whiteboard: [MemShrink]
Component: IPC → Drag and Drop
Whiteboard: [MemShrink] → [MemShrink:P3]
Priority: -- → P3

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.

You need to log in before you can comment on or make changes to this bug.