Regression: VSE crashes blender #120871

New Issue

Arnaud Schaer · 2024-04-21T12:22:51+02:00

Arnaud Schaer commented

2024-04-21 12:22:51 +02:00

System Information
Operating system: windows 10
Graphics card: RTX3090 (or RTX A1000on another system)

Blender Version
Broken: 4.1.0, 4.1.1
Worked: 4.0.2

Short description of error
I have a loooot of crashes of blender in VSE SINCE 4.1.0. I cannot pinpoint each, as they are numerous and not always reproductible, but it ranges from crash on :

moving the current frame
resizing a (meta) strip
moving a strip ...

But what is interesting here is a very simple scene. I don'say I always reproduce the crash with any file, but with the joined file I do :
it consists (after simplification) of only 1 strip, the audi strip of an mkv.

If :

I open the .blend with 4.1.0 or 4.1.1 : no issue ... yet.
now click on "video editing workspace" : blender crashes.
open the file with 4.0.2 : you can do anything it wont crash.
save the file with 4.0.2 : it still crashes 4.1.x (that's why I saved it in another workspace and not in VSE)
delete the audi strip, save the file : 4.1.x does not crash anymore.

I litterally spent 80% of my time recovering from crashes in VSE 4.1.x, and 90% of time when VSE crashes, .blend file AND .blend1 file are all corrupt.

since 4.1.x introduced numerous "improvements" (threading) to VSE please, can you investigate ? Because right now VSE is unusable for mo (and I'm a beginner, so I don't do furious things)

**System Information** Operating system: windows 10 Graphics card: RTX3090 (or RTX A1000on another system) **Blender Version** Broken: 4.1.0, 4.1.1 Worked: 4.0.2 **Short description of error** I have a loooot of crashes of blender in VSE SINCE 4.1.0. I cannot pinpoint each, as they are numerous and not always reproductible, but it ranges from crash on : - moving the current frame - resizing a (meta) strip - moving a strip ... But what is interesting here is a very simple scene. I don'say I always reproduce the crash with any file, but with the joined file I do : it consists (after simplification) of only 1 strip, the audi strip of an mkv. If : - I open the .blend with 4.1.0 or 4.1.1 : no issue ... yet. - now click on "video editing workspace" : blender crashes. - open the file with 4.0.2 : you can do anything it wont crash. - save the file with 4.0.2 : it still crashes 4.1.x (that's why I saved it in another workspace and not in VSE) - delete the audi strip, save the file : 4.1.x does not crash anymore. I litterally spent 80% of my time recovering from crashes in VSE 4.1.x, and 90% of time when VSE crashes, .blend file AND .blend1 file are all corrupt. since 4.1.x introduced numerous "improvements" (threading) to VSE please, can you investigate ? Because right now VSE is unusable for mo (and I'm a beginner, so I don't do furious things)

repro_crash_simplif.blend

2.5 MiB

Arnaud Schaer added the

labels 2024-04-21 12:22:52 +02:00

Aras Pranckevicius commented

2024-04-21 13:59:00 +02:00

Thanks for the report. I can reproduce the crash here, from the first look seems to not be related to any threading things, but rather to "retuming keys", whatever they are. Will investigate and try to fix.

Aras Pranckevicius added

and removed

labels 2024-04-21 13:59:31 +02:00

Iliya Katushenock changed title from ~~VSE crashes blender~~ to Regression: VSE crashes blender

2024-04-21 14:00:49 +02:00

Iliya Katushenock added the

Module

VFX & Video

label 2024-04-21 14:01:10 +02:00

Aras Pranckevicius self-assigned this 2024-04-21 14:06:29 +02:00

Aras Pranckevicius commented

2024-04-21 15:30:47 +02:00

From what I can tell, this seems to be caused by 4e10aa6e71 (fix for #115086), cc @iss. What happens now with this repro file is:

There's a single sound clip, from frames 0 to 193. However, the same clip has "hold offset start" set to frame 2188 (in code, seq->anim_startofs is 2188).

I don't even know what "hold offset start" is, but with these values this then happens inside SEQ_retiming_sound_animation_data_set (right at start of the function, i.e. code added by revision 4e10aa6e71):

BKE_sound_set_scene_sound_pitch_constant_range is called with frame_start=-2188 (note: negative), frame_end=0.
Which calls AUD_SequenceEntry_setConstantRangeAnimationData with the same frame range.
Which calls AnimateableProperty::writeConstantRange with the same frame range.
Code in there allocates buffer space only based on position_end, which is zero!
And then proceeds to write into negative buffer indices, corrupting other random memory.

Now, I don't understand any of this code, but it feels like maybe both of these might be true:

Inside Blender code of SEQ_retiming_sound_animation_data_set, maybe there's some sanitization / range check / clamping is needed, so that whatever the code is trying to do, does not result in garbage / out of range frame values that would be passed into audaspace.
Inside audaspace code of writeConstantRange, there's no validation of the inputs at all. It gets negative frames, it proceeds to corrupt memory. I don't even know if negative frame indices are valid inside audaspace. Maybe not?

From what I can tell, this seems to be caused by 4e10aa6e71 (fix for #115086), cc @iss. What happens now with this repro file is: - There's a single sound clip, from frames 0 to 193. However, the same clip has "hold offset start" set to frame 2188 (in code, `seq->anim_startofs` is 2188). I don't even know what "hold offset start" is, but with these values this then happens inside `SEQ_retiming_sound_animation_data_set` (right at start of the function, i.e. code added by revision 4e10aa6e71): - `BKE_sound_set_scene_sound_pitch_constant_range` is called with frame_start=-2188 (note: negative), frame_end=0. - Which calls `AUD_SequenceEntry_setConstantRangeAnimationData` with the same frame range. - Which calls `AnimateableProperty::writeConstantRange` with the same frame range. - Code in there allocates buffer space only based on `position_end`, which is zero! - And then proceeds to write into negative buffer indices, corrupting other random memory. Now, I don't understand any of this code, but it feels like maybe both of these might be true: - Inside Blender code of `SEQ_retiming_sound_animation_data_set`, maybe there's some sanitization / range check / clamping is needed, so that whatever the code is trying to do, does not result in garbage / out of range frame values that would be passed into audaspace. - Inside audaspace code of `writeConstantRange`, there's no validation of the inputs at all. It gets negative frames, it proceeds to corrupt memory. I don't even know if negative frame indices are valid inside audaspace. Maybe not?

Arnaud Schaer commented

2024-04-21 16:33:35 +02:00

Hi, "hold offset start/end" are set when "hard" cutting strips (instead of "strip offset start/end" when "soft" cutting strips )

Aras Pranckevicius referenced a pull request that will close this issue

2024-04-21 18:01:56 +02:00

Fix #120871: VSE crashes when sound strip has hold start offset larger than start #120891

Aras Pranckevicius referenced this issue from a commit

2024-04-22 14:44:17 +02:00

Fix #120871: VSE crashes when sound strip has hold start offset larger than start

Aras Pranckevicius closed this issue

2024-04-22 14:44:18 +02:00

Blender Bot added

and removed

labels 2024-04-22 14:45:38 +02:00

Richard Antalik commented

2024-04-23 01:59:56 +02:00

Indeed Audaspace can not handle negative offsets. Just sanitizing this with sound strips may cause AV sync issues, but it's the only solution. I think that hold offsets were forbidden for sound strips, not sure at what level, pretty sure RNA could set these anyway.

Sign in to join this conversation.

No Label

Download

What's New

Blender Studio

Manual

Developers Blog

Documentation

Benchmark

Blender Conference

Development Fund

One-time Donations

Regression: VSE crashes blender #120871