NEW 210966
clearkey-mp4-setmediakeys-again-after-playback.https.html occasionally crashes
https://bugs.webkit.org/show_bug.cgi?id=210966
Summary clearkey-mp4-setmediakeys-again-after-playback.https.html occasionally crashes
Charlie Turner
Reported 2020-04-24 05:20:34 PDT
When CDMInstanceProxy::startedWaitingForKey dispatches the the main thread, it's possible the MediaPlayer is still alive, but the associated client has been destroyed/corrupted somehow. void CDMInstanceProxy::startedWaitingForKey() │ │270 { │ │271 ASSERT(!isMainThread()); │ │272 ASSERT(m_player); │ │273 │ │274 bool wasWaitingForKey = m_numDecryptorsWaitingForKey > 0; │ │275 m_numDecryptorsWaitingForKey++; │ │276 │ │277 callOnMainThread([player = m_player, wasWaitingForKey] { │ │278 if (player && !wasWaitingForKey) │ >│279 player->waitingForKeyChanged(); │ │280 }); │ │281 } The player pointer is fine, then we go to, │1324 void MediaPlayer::waitingForKeyChanged() │ │1325 { │ >│1326 client().mediaPlayerWaitingForKeyChanged(); │ │1327 } And hit a SIGSEGV. The crash must be happening on client(), (gdb) p m_client $4 = (WebCore::MediaPlayerClient *) 0xffff70b58d48105d (gdb) p *m_client Cannot access memory at address 0xffff70b58d48105d That's a funny looking pointer address with the all the most-significant 1 bits. This must be some unpleasant JS GC interferance, I am unsure how this can be avoided from the CDMInstanceProxy POV.
Attachments
Note You need to log in before you can comment on or make changes to this bug.