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

Status: RESOLVED WORKSFORME

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

Description

[Ekanan Ketunuti]

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

[Jed Davis [:jld] ⟨⏰|UTC-8⟩ ⟦he/him⟧]

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.

Comment 2

[Chris Peterson [:cpeterson]]

I hit this crash when trying to take a page screenshot of https://protosaur.dev/fission-experiment-monitoring-dashboard/dashboard/dashboard.html.

bp-446e9783-0c1d-4961-b9ee-b7af40210318

Comment 3

[Jed Davis [:jld] ⟨⏰|UTC-8⟩ ⟦he/him⟧]

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

[Chris Peterson [:cpeterson]]

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

[BugBot [:suhaib / :marco/ :calixte]]

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

[BugBot [:suhaib / :marco/ :calixte]]

Closing because no crashes reported for 12 weeks.