Crash in objc_release called from PlayerCore.fileStarted #3822
Assignees
Comments
|
Sounds like something TSan would probably catch |
|
The thread sanitizer did not detect anything. Neither did other sanitizers I tried. Instead they detected an issue during termination. I entered a separate issue for that. The thread for I will keep an eye out, but this is the first time I've ever seen a crash in this area. Crashing Closure:// Auto load
backgroundQueueTicket += 1
let shouldAutoLoadFiles = info.shouldAutoLoadFiles
let currentTicket = backgroundQueueTicket
backgroundQueue.async {
// add files in same folder
if shouldAutoLoadFiles {
Logger.log("Started auto load", subsystem: self.subsystem)
self.autoLoadFilesInCurrentFolder(ticket: currentTicket)
}
// auto load matched subtitles
if let matchedSubs = self.info.matchedSubs[path] {
Logger.log("Found \(matchedSubs.count) subs for current file", subsystem: self.subsystem)
for sub in matchedSubs {
guard currentTicket == self.backgroundQueueTicket else { return }
self.loadExternalSubFile(sub)
}
// set sub to the first one
guard currentTicket == self.backgroundQueueTicket, self.mpv.mpv != nil else { return }
self.setTrack(1, forType: .sub)
}
self.autoSearchOnlineSub()
} |
1 task
|
I looked into this some more. I suspect the TSan reported data race shown below is to blame. Multiple threads are accessing I've added this to my list of thread related failures I need to address. Xcode Console: |
low-batt
added a commit
that referenced
this issue
Apr 9, 2023
This commit will: - Add Atomic to PlaybackInfo.matchedSubs - Add a getMatchedSubs method to PlaybackInfo - Change AutoFileMatcher, PlayerCore and PlaylistViewController to hold a lock while accessing matchedSubs - Add Atomic to PlayerCore.backgroundQueueTicket - Change PlayerCore.fileStarted to hold a lock while incrementing backgroundQueueTicket - Add code to PlayerCore.stop that increments backgroundQueueTicket These changes insure the mutable Swift dictionary matchedSubs is only accessed by one thread at a time. Accessing a mutable dictionary from multiple threads without such coordination can result in a crash as seen in issue #3822. These changes also attempt to insure the background task that finds and loads subtitle files stops its work if playback is stopped before that process completes.
2 tasks
2 tasks
uiryuu
pushed a commit
that referenced
this issue
Apr 23, 2023
This commit will: - Add Atomic to PlaybackInfo.matchedSubs - Add a getMatchedSubs method to PlaybackInfo - Change AutoFileMatcher, PlayerCore and PlaylistViewController to hold a lock while accessing matchedSubs - Add Atomic to PlayerCore.backgroundQueueTicket - Change PlayerCore.fileStarted to hold a lock while incrementing backgroundQueueTicket - Add code to PlayerCore.stop that increments backgroundQueueTicket These changes insure the mutable Swift dictionary matchedSubs is only accessed by one thread at a time. Accessing a mutable dictionary from multiple threads without such coordination can result in a crash as seen in issue #3822. These changes also attempt to insure the background task that finds and loads subtitle files stops its work if playback is stopped before that process completes.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
System and IINA version:
Expected behavior:
IINA does not crash.
Actual behavior:
IINA crashed before playing the file.
Crash report:
Steps to reproduce:
I've not been able to reproduce this crash. Hopefully the crash report identifies the issue.
Unknown, but likely not given location of crash.
How often does this happen?
So far only once.
The text was updated successfully, but these errors were encountered: