Bug 210966
Summary: | clearkey-mp4-setmediakeys-again-after-playback.https.html occasionally crashes | ||
---|---|---|---|
Product: | WebKit | Reporter: | Charlie Turner <cturner> |
Component: | WebKitGTK | Assignee: | Nobody <webkit-unassigned> |
Status: | NEW | ||
Severity: | Normal | CC: | bugs-noreply |
Priority: | P2 | ||
Version: | WebKit Nightly Build | ||
Hardware: | Unspecified | ||
OS: | Unspecified |
Charlie Turner
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. |