WebKit Bugzilla
New
Browse
Log In
×
Sign in with GitHub
or
Remember my login
Create Account
·
Forgot Password
Forgotten password account recovery
RESOLVED FIXED
201222
[GStreamer] Do not ref the player count from background threads.
https://bugs.webkit.org/show_bug.cgi?id=201222
Summary
[GStreamer] Do not ref the player count from background threads.
Charlie Turner
Reported
2019-08-28 09:05:36 PDT
[GStreamer] Do not ref the player count from background threads.
Attachments
Patch
(10.04 KB, patch)
2019-08-28 09:13 PDT
,
Charlie Turner
no flags
Details
Formatted Diff
Diff
Patch for landing
(10.04 KB, patch)
2019-08-30 03:18 PDT
,
Charlie Turner
no flags
Details
Formatted Diff
Diff
Patch for landing
(10.04 KB, patch)
2019-08-30 03:19 PDT
,
Charlie Turner
no flags
Details
Formatted Diff
Diff
Show Obsolete
(2)
View All
Add attachment
proposed patch, testcase, etc.
Charlie Turner
Comment 1
2019-08-28 09:13:22 PDT
Created
attachment 377451
[details]
Patch
Xabier Rodríguez Calvar
Comment 2
2019-08-29 07:46:27 PDT
Comment on
attachment 377451
[details]
Patch View in context:
https://bugs.webkit.org/attachment.cgi?id=377451&action=review
Good! Only a couple of things to tweak before landing.
> Source/WebCore/platform/graphics/gstreamer/MediaPlayerPrivateGStreamerBase.cpp:353 > + if (m_cdmAttachmentSemaphore.waitFor(4_s) > + && m_notifier->isValid() // Check the player is not being destroyed. > + && !m_cdmInstance->keySystem().isEmpty()) {
We need to consider here, to avoid any other crashes, that the semaphore can be either signaled by the destructor or that the timeout can be hit, both without the instance being set. It looks like the third clause with crash is m_cdmInstance is still null. Besides, all this can be one line.
> Source/WebCore/platform/graphics/gstreamer/MediaPlayerPrivateGStreamerBase.h:308 > + Lock m_protectionMutex; // Guards access to m_handledProtectionEvents
.
Xabier Rodríguez Calvar
Comment 3
2019-08-29 07:46:53 PDT
Comment on
attachment 377451
[details]
Patch View in context:
https://bugs.webkit.org/attachment.cgi?id=377451&action=review
> Source/WebCore/platform/graphics/gstreamer/MediaPlayerPrivateGStreamerBase.h:307 > +
And you can remove this line
Charlie Turner
Comment 4
2019-08-29 08:29:01 PDT
(In reply to Xabier Rodríguez Calvar from
comment #2
)
> Comment on
attachment 377451
[details]
> Patch > > View in context: >
https://bugs.webkit.org/attachment.cgi?id=377451&action=review
> > Good! Only a couple of things to tweak before landing. > > > Source/WebCore/platform/graphics/gstreamer/MediaPlayerPrivateGStreamerBase.cpp:353 > > + if (m_cdmAttachmentSemaphore.waitFor(4_s) > > + && m_notifier->isValid() // Check the player is not being destroyed. > > + && !m_cdmInstance->keySystem().isEmpty()) { > > We need to consider here, to avoid any other crashes, that the semaphore can > be either signaled by the destructor or that the timeout can be hit, both > without the instance being set. It looks like the third clause with crash is > m_cdmInstance is still null.
There are two cases, 1) Signal from cdmInstanceAttached. In this case, we know the cdmInstance is not null 2) Signal from dtor, in this case the notifier will have been cancelled in the dtor already, and the second conditional will bail out. So we don't need a further check imo.
> Besides, all this can be one line.
We then lose the informative comment about why isValid() is there, it's much easier to read conditionals vertically aligned like this and to comment on their conditions.
Xabier Rodríguez Calvar
Comment 5
2019-08-29 23:38:00 PDT
(In reply to Charlie Turner from
comment #4
)
> > > Source/WebCore/platform/graphics/gstreamer/MediaPlayerPrivateGStreamerBase.cpp:353 > > > + if (m_cdmAttachmentSemaphore.waitFor(4_s) > > > + && m_notifier->isValid() // Check the player is not being destroyed. > > > + && !m_cdmInstance->keySystem().isEmpty()) { > > > > We need to consider here, to avoid any other crashes, that the semaphore can > > be either signaled by the destructor or that the timeout can be hit, both > > without the instance being set. It looks like the third clause with crash is > > m_cdmInstance is still null. > > There are two cases, > 1) Signal from cdmInstanceAttached. In this case, we know the cdmInstance > is not null > 2) Signal from dtor, in this case the notifier will have been cancelled in > the dtor already, and the second conditional will bail out.
3) waitFor timeout runs out without being signalled from anywhere.
> So we don't need a further check imo. > > > Besides, all this can be one line. > > We then lose the informative comment about why isValid() is there, it's much > easier to read conditionals vertically aligned like this and to comment on > their conditions.
Right.
Charlie Turner
Comment 6
2019-08-30 03:00:33 PDT
(In reply to Xabier Rodríguez Calvar from
comment #5
)
> (In reply to Charlie Turner from
comment #4
) > > > > Source/WebCore/platform/graphics/gstreamer/MediaPlayerPrivateGStreamerBase.cpp:353 > > > > + if (m_cdmAttachmentSemaphore.waitFor(4_s) > > > > + && m_notifier->isValid() // Check the player is not being destroyed. > > > > + && !m_cdmInstance->keySystem().isEmpty()) { > > > > > > We need to consider here, to avoid any other crashes, that the semaphore can > > > be either signaled by the destructor or that the timeout can be hit, both > > > without the instance being set. It looks like the third clause with crash is > > > m_cdmInstance is still null. > > > > There are two cases, > > 1) Signal from cdmInstanceAttached. In this case, we know the cdmInstance > > is not null > > 2) Signal from dtor, in this case the notifier will have been cancelled in > > the dtor already, and the second conditional will bail out. > > 3) waitFor timeout runs out without being signalled from anywhere.
And in that case, waitFor() returns false.
> > > > So we don't need a further check imo. > > > > > Besides, all this can be one line. > > > > We then lose the informative comment about why isValid() is there, it's much > > easier to read conditionals vertically aligned like this and to comment on > > their conditions. > > Right.
Xabier Rodríguez Calvar
Comment 7
2019-08-30 03:02:52 PDT
We good then.
Charlie Turner
Comment 8
2019-08-30 03:18:18 PDT
Created
attachment 377692
[details]
Patch for landing
Charlie Turner
Comment 9
2019-08-30 03:19:13 PDT
Created
attachment 377693
[details]
Patch for landing
WebKit Commit Bot
Comment 10
2019-08-30 04:02:25 PDT
Comment on
attachment 377693
[details]
Patch for landing Clearing flags on attachment: 377693 Committed
r249321
: <
https://trac.webkit.org/changeset/249321
>
WebKit Commit Bot
Comment 11
2019-08-30 04:02:26 PDT
All reviewed patches have been landed. Closing bug.
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