Blender crashes using Jack with AV Sync enabled (repeatable) #72632

New Issue

Casey Connor · 2019-12-22T02:58:28+01:00

Casey Connor commented

2019-12-22 02:58:28 +01:00

System Information
Operating system: Linux-4.18.0-25-generic-x86_64-with-debian-buster-sid 64 Bits
Graphics card: GeForce GTX 1060 6GB/PCIe/SSE2 NVIDIA Corporation 4.5.0 NVIDIA 390.116

Blender Version
Broken: version: 2.81 (sub 16), branch: master, commit date: 2019-12-04 11:32, hash: f1aa4d18d4

Short description of error

Blender crashes while scrubbing when AV Sync is enabled and system is using JACK audio

Exact steps for others to reproduce the error

open blender 2.81a with fresh config dir
enter prefs -> System and choose JACK as audio device
go to VSE, add audio clip of whatever length to at least fill the default frames (I used a standard stereo 16bit PCM .wav in this case)
in Timeline, enable AV Sync option
play the animation, and scrub around with the mouse on the timeline

It takes a while of constant scrubbing for me -- sometimes 30 seconds or even 1-2 minutes, but I can reliably make Blender crash this way. (Sometimes I stop and jump around in the timeline, left/right-arrow a little, etc... not sure if any of that is necessary.) Two crash.txt's are attached.

blender.crash_jack.txt

blender.crash2_jack.txt

Developer note

The issue is caused by race condition between JACK callback and dependency graph update.

One of the ideas to get it solved is to make JACK callback to act more like a tag (rahtehr than an actual action) which will allow handling it as soon as possible but not from the place where it can't be happening in a thread-safe manner.

**System Information** Operating system: Linux-4.18.0-25-generic-x86_64-with-debian-buster-sid 64 Bits Graphics card: GeForce GTX 1060 6GB/PCIe/SSE2 NVIDIA Corporation 4.5.0 NVIDIA 390.116 **Blender Version** Broken: version: 2.81 (sub 16), branch: master, commit date: 2019-12-04 11:32, hash: `f1aa4d18d4` **Short description of error** Blender crashes while scrubbing when AV Sync is enabled and system is using JACK audio **Exact steps for others to reproduce the error** * open blender 2.81a with fresh config dir * enter prefs -> System and choose JACK as audio device * go to VSE, add audio clip of whatever length to at least fill the default frames (I used a standard stereo 16bit PCM .wav in this case) * in Timeline, enable AV Sync option * play the animation, and scrub around with the mouse on the timeline It takes a while of constant scrubbing for me -- sometimes 30 seconds or even 1-2 minutes, but I can reliably make Blender crash this way. (Sometimes I stop and jump around in the timeline, left/right-arrow a little, etc... not sure if any of that is necessary.) Two crash.txt's are attached. [blender.crash_jack.txt](https://archive.blender.org/developer/F8239979/blender.crash_jack.txt) [blender.crash2_jack.txt](https://archive.blender.org/developer/F8239980/blender.crash2_jack.txt) ---- **Developer note** The issue is caused by race condition between JACK callback and dependency graph update. One of the ideas to get it solved is to make JACK callback to act more like a tag (rahtehr than an actual action) which will allow handling it as soon as possible but not from the place where it can't be happening in a thread-safe manner.

Casey Connor commented

2019-12-22 02:58:28 +01:00

Added subscriber: @clepsydrae

Jacques Lucke commented

2019-12-29 13:03:11 +01:00

Added subscriber: @neXyon

Philipp Oeser commented

2020-01-21 15:26:58 +01:00

Added subscriber: @lichtwerk

Philipp Oeser commented

2020-01-21 15:26:58 +01:00

Changed status from 'Needs Triage' to: 'Confirmed'

Philipp Oeser commented

2020-01-21 15:26:58 +01:00

Can confirm in a buildbot build.
(havent built with JACK myself yet, but...confirming for now)

Can confirm in a buildbot build. (havent built with JACK myself yet, but...confirming for now)

Sergey Sharybin was assigned by Joerg Mueller

2020-01-25 16:59:34 +01:00

Joerg Mueller commented

2020-01-25 16:59:34 +01:00

The crash happens as follows, when you use JACK and AV-sync, JACK transport is enabled meaning that JACK will call the sound_sync_callback, which down the road

sound_sync_callback -> sound_jack_sync_callback -> BKE_sound_jack_scene_update -> BKE_sound_play_scene -> sound_start_play_scene -> AUD_Device_play

leads to sound (in sound_start_play_scene it's scene->sound_scene) being NULL.

I figured that this is due to SceneBackup setting it so in Blender's main thread, but that's as far as I can get since I don't know what this is for. While there is a chance that sound is playing back, sound_scene should only be changed when the audio device is locked (AUD_Device_lock(sound_device); ...; AUD_Device_unlock(sound_device);), however, locking the device should be as short as possible it will cause skips, clicks, other nasty sounds, hangs, etc...

The crash happens as follows, when you use JACK and AV-sync, JACK transport is enabled meaning that JACK will call the `sound_sync_callback`, which down the road ``` sound_sync_callback -> sound_jack_sync_callback -> BKE_sound_jack_scene_update -> BKE_sound_play_scene -> sound_start_play_scene -> AUD_Device_play ``` leads to `sound` (in `sound_start_play_scene` it's `scene->sound_scene`) being `NULL`. I figured that this is due to `SceneBackup` setting it so in Blender's main thread, but that's as far as I can get since I don't know what this is for. While there is a chance that sound is playing back, `sound_scene` should only be changed when the audio device is locked (`AUD_Device_lock(sound_device); ...; AUD_Device_unlock(sound_device);`), however, locking the device should be as short as possible it will cause skips, clicks, other nasty sounds, hangs, etc...

Sergey Sharybin removed their assignment 2020-03-13 14:43:58 +01:00

Sergey Sharybin commented

2020-03-13 14:43:58 +01:00

Added subscriber: @Sergey

Sergey Sharybin commented

2020-03-13 14:43:58 +01:00

Having a callback happening from the middle of dependency graph update will never be reliable.

The proper behavior would be to do some sort of tag from the sound_jack_sync_callback which will indicate that the current frame and audio is to be updated once the event loop allows this.

Unassigning myself, it doesn't fir into my agenda. Can help with understanding the design, but can't be the one who fixes every single area.

Having a callback happening from the middle of dependency graph update will never be reliable. The proper behavior would be to do some sort of tag from the `sound_jack_sync_callback` which will indicate that the current frame and audio is to be updated once the event loop allows this. Unassigning myself, it doesn't fir into my agenda. Can help with understanding the design, but can't be the one who fixes every single area.

Sergey Sharybin commented

2020-03-13 14:45:26 +01:00

Removed subscriber: @Sergey