Closed Bug 1196119 Opened 9 years ago Closed 8 years ago

e10s crash when playing video with APZ on OS X: IPDL protocol error: Error deserializing 'data' (Shmem) member of 'SurfaceDescriptorShmem'


(Core :: Panning and Zooming, defect, P1)




Tracking Status
e10s + ---
firefox42 --- unaffected
firefox43 --- wontfix
firefox45 --- wontfix
firefox46 --- fixed
firefox47 --- unaffected


(Reporter: cpeterson, Unassigned)



(Keywords: crash, regression, reproducible)

When testing MSE bug 1189987, I hit this e10s crash.

1. Enable e10s.
2. Load
3. Paste this manifest URL into the video player:
4. Press the LOAD and then play button.

The tab crashes! If the tab doesn't crash within a couple seconds, reload the page and try again.

No crash report is logged to about:crashes, but the following error messages are logged to stdout:

###!!! [Child][DispatchAsyncMessage] Error: (msgtype=0xFFFB,name=???) Payload error: message could not be deserialized

IPDL protocol error: Error deserializing 'data' (Shmem) member of 'SurfaceDescriptorShmem'
IPDL protocol error: Error deserializing 'SurfaceDescriptor'

###!!! [Child][DispatchAsyncMessage] Error: (msgtype=0x800006,name=PLayerTransaction::Msg_PTextureConstructor) Value error: message was deserialized, but contained an illegal value

###!!! [Parent][MessageChannel] Error: (msgtype=0x200084,name=PBrowser::Msg_Destroy) Channel error: cannot send/recv
@ Kats, I bisected this crash to this pushlog, which implicates APZ on OS X:

I can reproduce this crash on my MacBook Pro's Retina display, but not on an external non-HiDPI display.
Blocks: 1157746
Component: Audio/Video: Playback → Panning and Zooming
Flags: needinfo?(bugmail.mozilla)
Summary: e10s crash when playing video: IPDL protocol error: Error deserializing 'data' (Shmem) member of 'SurfaceDescriptorShmem' → e10s crash when playing video with APZ on OS X: IPDL protocol error: Error deserializing 'data' (Shmem) member of 'SurfaceDescriptorShmem'
:nical, any ideas what's going on here? I poked around in the IPDL code and it would appear that this happens if the child cannot create a shmem from the info the parent provided (either the bytes are bad or the shmem id is invalid). Not really sure why this would be APZ-specific though.

cpeterson, if you are able to attach a debugger to the child process and see why the shmem deserializing is failing that might help. The relevant code is generated into objdir/ipc/ipdl/PLayerTransactionChild.cpp: the function is PLayerTransaction::Read(Shmem* v__, const Message* msg__, void** iter__) - this is returning false when it shouldn't be.
Flags: needinfo?(bugmail.mozilla) → needinfo?(nical.bugzilla)
(I'm also not able to repro this on my non-retina mac air)
The reproduction steps work on my machine.
Flags: needinfo?(nical.bugzilla)
Is this still reproducible?
Flags: needinfo?(cpeterson)
(Please check both 46 and 47 if you have a chance. If it's only fixed in 47, we should uplift whatever fixed it to 46)
The crash is reproducible in Aurora 46, but not Nightly 47.

Note that the manifest.mpd URL in comment 0's STR is 404. You can reproduce the crash with this mpd URL:
Flags: needinfo?(cpeterson)
Thanks! We should get a fix window and see if we can uplift whatever fixed it. Adding regression-window keyword but really we need a reverse-regression window between 46 and 47.
Kats, I bisected the fix with mozregression to bug 1208226, which is pending uplift approval for Aurora 46 and Beta 45. Do you want to close this bug as FIXED by bug 1208226? Or wait until that fix has been uplifted and this bug's STR retested?
Depends on: 1208226
Thanks, Chris! I'll mark this as FIXED and leave a comment in the other bug which might help with the uplift decision. We can reverify once the patch is uplifted.
Closed: 8 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.