Bug 236279 - AudioBuffer should take a lock while visiting m_channelWrappers
Summary: AudioBuffer should take a lock while visiting m_channelWrappers
Status: RESOLVED FIXED
Alias: None
Product: WebKit
Classification: Unclassified
Component: Web Audio (show other bugs)
Version: WebKit Nightly Build
Hardware: Unspecified Unspecified
: P2 Normal
Assignee: Yusuke Suzuki
URL:
Keywords: InRadar
Depends on:
Blocks:
 
Reported: 2022-02-07 19:42 PST by Yusuke Suzuki
Modified: 2022-02-09 13:34 PST (History)
12 users (show)

See Also:


Attachments
Patch (16.46 KB, patch)
2022-02-09 01:31 PST, Yusuke Suzuki
keith_miller: review+
Details | Formatted Diff | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Yusuke Suzuki 2022-02-07 19:42:47 PST
Since the vector is cleared in releaseMemory.
Comment 1 Yusuke Suzuki 2022-02-09 01:31:10 PST
Created attachment 451347 [details]
Patch
Comment 2 Keith Miller 2022-02-09 07:02:22 PST
Comment on attachment 451347 [details]
Patch

r=me.
Comment 3 Chris Dumez 2022-02-09 07:26:42 PST
Comment on attachment 451347 [details]
Patch

View in context: https://bugs.webkit.org/attachment.cgi?id=451347&action=review

> Source/WebCore/Modules/webaudio/AudioBuffer.cpp:95
> +    channels.reserveCapacity(numberOfChannels);

should be reserveInitialCapacity()

> Source/WebCore/Modules/webaudio/AudioBuffer.cpp:107
> +        channels.append(WTFMove(channelDataArray));

could use uncheckedAppend() since you reserve capacity.

> Source/WebCore/Modules/webaudio/AudioBuffer.cpp:126
> +    channels.reserveCapacity(numberOfChannels);

ditto.

> Source/WebCore/Modules/webaudio/AudioBuffer.cpp:135
> +        channels.append(WTFMove(channelDataArray));

ditto.

> Source/WebCore/Modules/webaudio/AudioBuffer.h:102
> +    FixedVector<RefPtr<Float32Array>> m_channels;

Would be nice to use WTF_GUARDED_BY_LOCK(m_channelsLock);

> Source/WebCore/Modules/webaudio/AudioBuffer.h:103
> +    FixedVector<JSValueInWrappedObject> m_channelWrappers;

ditto.

> Source/WebCore/dom/MessageEvent.h:104
> +    mutable Lock m_concurrentDataAccessLock;

Can we use clang thread safety annotations?
Comment 4 Yusuke Suzuki 2022-02-09 08:56:19 PST
Comment on attachment 451347 [details]
Patch

View in context: https://bugs.webkit.org/attachment.cgi?id=451347&action=review

>> Source/WebCore/Modules/webaudio/AudioBuffer.cpp:95
>> +    channels.reserveCapacity(numberOfChannels);
> 
> should be reserveInitialCapacity()

Fixed.

>> Source/WebCore/Modules/webaudio/AudioBuffer.cpp:107
>> +        channels.append(WTFMove(channelDataArray));
> 
> could use uncheckedAppend() since you reserve capacity.

Fixed.

>> Source/WebCore/Modules/webaudio/AudioBuffer.cpp:126
>> +    channels.reserveCapacity(numberOfChannels);
> 
> ditto.

Fixed.

>> Source/WebCore/Modules/webaudio/AudioBuffer.cpp:135
>> +        channels.append(WTFMove(channelDataArray));
> 
> ditto.

Fixed.

>> Source/WebCore/Modules/webaudio/AudioBuffer.h:102
>> +    FixedVector<RefPtr<Float32Array>> m_channels;
> 
> Would be nice to use WTF_GUARDED_BY_LOCK(m_channelsLock);

Probably, TSan does not work well here since,
1. We are not taking a lock in the main thread read since we know that any other threads except the main thread will not change it.
2. But we take a lock when reading it from concurrent threads since it can be modified from the main thread.
Comment 5 Yusuke Suzuki 2022-02-09 09:06:27 PST
Committed r289476 (247019@trunk): <https://commits.webkit.org/247019@trunk>
Comment 6 Radar WebKit Bug Importer 2022-02-09 09:07:17 PST
<rdar://problem/88693354>
Comment 7 Chris Dumez 2022-02-09 09:08:36 PST
(In reply to Yusuke Suzuki from comment #4)
> Comment on attachment 451347 [details]
> Patch
> 
> View in context:
> https://bugs.webkit.org/attachment.cgi?id=451347&action=review
> 
> >> Source/WebCore/Modules/webaudio/AudioBuffer.cpp:95
> >> +    channels.reserveCapacity(numberOfChannels);
> > 
> > should be reserveInitialCapacity()
> 
> Fixed.
> 
> >> Source/WebCore/Modules/webaudio/AudioBuffer.cpp:107
> >> +        channels.append(WTFMove(channelDataArray));
> > 
> > could use uncheckedAppend() since you reserve capacity.
> 
> Fixed.
> 
> >> Source/WebCore/Modules/webaudio/AudioBuffer.cpp:126
> >> +    channels.reserveCapacity(numberOfChannels);
> > 
> > ditto.
> 
> Fixed.
> 
> >> Source/WebCore/Modules/webaudio/AudioBuffer.cpp:135
> >> +        channels.append(WTFMove(channelDataArray));
> > 
> > ditto.
> 
> Fixed.
> 
> >> Source/WebCore/Modules/webaudio/AudioBuffer.h:102
> >> +    FixedVector<RefPtr<Float32Array>> m_channels;
> > 
> > Would be nice to use WTF_GUARDED_BY_LOCK(m_channelsLock);
> 
> Probably, TSan does not work well here since,
> 1. We are not taking a lock in the main thread read since we know that any
> other threads except the main thread will not change it.
> 2. But we take a lock when reading it from concurrent threads since it can
> be modified from the main thread.

For what it's worth, this is an example of case where I would use annotations but add WTF_IGNORES_THREAD_SAFETY_ANALYSIS on the functions that fail to lock (with a comment explaining WHY this is ok/safe). I worked hard on adopting annotations in existing code, we should use them in new code too.
Comment 8 Darin Adler 2022-02-09 13:34:00 PST
Comment on attachment 451347 [details]
Patch

View in context: https://bugs.webkit.org/attachment.cgi?id=451347&action=review

> Source/WebCore/bindings/js/JSValueInWrappedObject.h:41
> +    WTF_MAKE_NONMOVABLE(JSValueInWrappedObject);

This does nothing. WTF_MAKE_NONCOPYABLE already makes things non-movable. There should not be a second macro.

> Source/WebCore/bindings/js/JSValueInWrappedObject.h:-45
> -    // FIXME: Remove them once AudioBuffer's m_channelWrappers bug is fixed.
> -    // https://bugs.webkit.org/show_bug.cgi?id=236279
> -    JSValueInWrappedObject(JSValueInWrappedObject&&) = default;
> -    JSValueInWrappedObject& operator=(JSValueInWrappedObject&&) = default;

Removing this is sufficient to make the thing non-movable.