Data race detected by thread sanitizer on WhisperKit.progress instance variable.

[clindsay3]

The progress instance variable on WhisperKit is not being properly protected from data races.

Since WhisperKit is not actor-isolated, access to progress in the runTranscribeTask method can occur on multiple threads.

When I run in my own app and enable the thread sanitizer in the scheme diagnostic options, it detects this section as a data race:

if progress.isFinished {
   // Reset progress if it is completed
   progress = Progress()
}

Here's the detailed thread sanitizer report:

WARNING: ThreadSanitizer: data race (pid=51838)
  Read of size 8 at 0x000106e68c58 by thread T29:
    #0 WhisperKit.WhisperKit.progress.getter : __C.NSProgress <null> (TranscrybeCore:arm64+0x2c5428)
    #1 (5) suspend resume partial function for WhisperKit.WhisperKit.runTranscribeTask(audioArray: Swift.Array<Swift.Float>, decodeOptions: Swift.Optional<WhisperKit.DecodingOptions>, callback: Swift.Optional<(WhisperKit.TranscriptionProgress) -> Swift.Optional<Swift.Bool>>) async throws -> Swift.Array<WhisperKit.TranscriptionResult> <null> (TranscrybeCore:arm64+0x2fac20)
    #2 swift::runJobInEstablishedExecutorContext(swift::Job*) <null> (libswift_Concurrency.dylib:arm64e+0x5c450)

  Previous write of size 8 at 0x000106e68c58 by thread T35:
    #0 (5) suspend resume partial function for WhisperKit.WhisperKit.runTranscribeTask(audioArray: Swift.Array<Swift.Float>, decodeOptions: Swift.Optional<WhisperKit.DecodingOptions>, callback: Swift.Optional<(WhisperKit.TranscriptionProgress) -> Swift.Optional<Swift.Bool>>) async throws -> Swift.Array<WhisperKit.TranscriptionResult> <null> (TranscrybeCore:arm64+0x2fad34)
    #1 swift::runJobInEstablishedExecutorContext(swift::Job*) <null> (libswift_Concurrency.dylib:arm64e+0x5c450)

  Location is heap block of size 712 at 0x000106e68a00 allocated by main thread:
    #0 malloc <null> (libclang_rt.tsan_osx_dynamic.dylib:arm64e+0x55fb4)
    #1 _malloc_type_malloc_outlined <null> (libsystem_malloc.dylib:arm64e+0x1da80)
    #2 swift::runJobInEstablishedExecutorContext(swift::Job*) <null> (libswift_Concurrency.dylib:arm64e+0x5c450)
    #3 __debug_main_executable_dylib_entry_point <null> (Transcrybe.debug.dylib:arm64+0x7ed0)
    #4 <null> <null> (0x000193a1ab4c)

  Thread T29 (tid=6180198, running) is a GCD worker thread

  Thread T35 (tid=6180204, running) is a GCD worker thread

SUMMARY: ThreadSanitizer: data race (/Users/chris/Library/Developer/Xcode/DerivedData/Transcrybe-hbenxjemepmsovdjjuucnlyerfnc/Build/Products/Debug/Transcrybe.app/Contents/Frameworks/TranscrybeCore.framework/Versions/A/TranscrybeCore:arm64+0x2c5428) in WhisperKit.WhisperKit.progress.getter : __C.NSProgress+0x38

[ZachNagengast]

Thanks for the report! Have you noticed any issues during development from this data race? While we don't have strict concurrency enabled right now, it is planned before v1.0.0 is released. Also, with the default main actor coming, this may be mitigated somewhat in a future Swift build.

[clindsay3]

Thanks @ZachNagengast !

I'm not sure if it's causing issues, maybe?

I've been trying to debug crashes in my app that look like some sort of memory corruption, and this is the first thing that popped out to me. My app is doing live transcription from the microphone, calling transcribe many times, so this data race gets flagged over and over again, which seems suspicious to me.

On the other hand, I am calling WhisperKit.transcribe from only one location in my code, and it's main actor isolated with a check around the call to prevent multiple calls to transcribe from happening at the same time. So I think in practice I'm insulating myself from the effects of this data race. But I'm still wrapping my head around Swift Concurrency, so I could be mistaken.