WebKit Bugzilla
New
Browse
Log In
×
Sign in with GitHub
or
Remember my login
Create Account
·
Forgot Password
Forgotten password account recovery
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
Add attachment
proposed patch, testcase, etc.
Note
You need to
log in
before you can comment on or make changes to this bug.
Top of Page
Format For Printing
XML
Clone This Bug