1463831 - [Parent][DispatchAsyncMessage] Error: SHMEM_CREATED_MESSAGE Payload error: message could not be deserialized

Status: NEW

(Core :: IPC, defect, P3)

Description

[Henrik Skupin [:whimboo][⌚️UTC+1]]

Running web-platform-tests reftests locally on my Mac with a debug artifact build I see the following error in the log output:

> 0:14.48 pid:37106 [Parent 37106, Compositor] WARNING: Shmem was deallocated: file /builds/worker/workspace/build/src/ipc/glue/Shmem.cpp, line 384
> 0:14.49 pid:37106 ###!!! [Parent][DispatchAsyncMessage] Error: SHMEM_CREATED_MESSAGE Payload error: message could not be deserialized

Command to run:

mach wpt testing/web-platform/tests/webvtt/rendering/cues-with-video/processing-model/ --pause-on-unexpected

The failure is visible a couple of times for the test 2_cues_overlapping_partially_move_up.html.

Maybe a left-over from the fix for bug 1362303 or something completely different?

Comment 1

[Stephen A Pohl [:spohl]]

The call to Shmem::OpenExisting is failing here with a warning that Shmem was deallocated. This does not appear to be related to bug 1362303 where we were dealing with a failure to map shared memory. Also, I'm unable to reproduce this with a local build.

Comment 2

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

This looks like it can happen if an ipc::Shmem is created and then destroyed before being used — when it's created, a SHMEM_CREATED_MESSAGE is sent to the other side of the associated top-level actor, going through the usual queues and event loops, but destruction (Shmem::Dealloc) writes directly to the memory to zero out the debug sentinels. 

Non-debug builds don't appear to do anything special to mark deallocated segments, so Shmem::OpenExisting would succeed and they wouldn't have this problem.

If I'm right about this, it could happen on any platform, but the Mac shared memory implementation is more complex so it's possible that there's a larger window for this race condition.