Blender Crashes Frequently with Timeline Scrub #71621

New Issue

Tyler Walker · 2019-11-16T06:06:27+01:00

Tyler Walker commented

2019-11-16 06:06:27 +01:00

System Information
Operating system: Windows-10-10.0.18362 64 Bits
Graphics card: Radeon RX 580 Series ATI Technologies Inc. 4.5.13571 Core Profile Context 19.10.1 26.20.13025.10004

Blender Version
Broken: version: 2.80 (sub 75), branch: master, commit date: 2019-07-29 14:47, hash: f6cb5f5449
Worked: (optional)

Short description of error
I have a relatively simple scene with one character+rig+animations, a few static meshes, one camera, two lights, and one simple particle emitter. Scrubbing through the timeline causes blender to crash very frequently, making animation impossibly difficult. One thing to note is I have several modifiers in place to displace the flames on the character's body, disabling them doesn't seem to make a difference for me; in addition, I also have a complex material setup for the flames which uses panning textures.

Exact steps for others to reproduce the error

VSE_sound_crash.blend

Open the above file
go to frame 172 or scrub past that frame
see crash

All that's left is a single sound strip in the Video Sequence Editor. If you play animation it works fine.

Other steps with a bigger file:

Endeavor_AutoRigPro_Test.blend

Open the attached file
Play the animation first as I'm quite proud of it ;)
Scrub through the timeline a little and watch blender crash.

**System Information** Operating system: Windows-10-10.0.18362 64 Bits Graphics card: Radeon RX 580 Series ATI Technologies Inc. 4.5.13571 Core Profile Context 19.10.1 26.20.13025.10004 **Blender Version** Broken: version: 2.80 (sub 75), branch: master, commit date: 2019-07-29 14:47, hash: `f6cb5f5449` Worked: (optional) **Short description of error** I have a relatively simple scene with one character+rig+animations, a few static meshes, one camera, two lights, and one simple particle emitter. Scrubbing through the timeline causes blender to crash very frequently, making animation impossibly difficult. One thing to note is I have several modifiers in place to displace the flames on the character's body, disabling them doesn't seem to make a difference for me; in addition, I also have a complex material setup for the flames which uses panning textures. **Exact steps for others to reproduce the error** [VSE_sound_crash.blend](https://archive.blender.org/developer/F8147157/VSE_sound_crash.blend) 1) Open the above file 2) go to frame 172 or scrub past that frame 3) see crash All that's left is a single sound strip in the Video Sequence Editor. If you play animation it works fine. Other steps with a bigger file: [Endeavor_AutoRigPro_Test.blend](https://archive.blender.org/developer/F8100764/Endeavor_AutoRigPro_Test.blend) 1) Open the attached file 2) Play the animation first as I'm quite proud of it ;) 3) Scrub through the timeline a little and watch blender crash.

Tyler Walker commented

2019-11-16 06:06:27 +01:00

Added subscriber: @tyler.tofu

Marcin Twarowski commented

2019-11-18 09:38:45 +01:00

Added subscriber: @MarcinTwarowski

Marcin Twarowski commented

2019-11-18 09:38:45 +01:00

I can confirm. It always crashes at frame 172. Not only when scrubbing, simply setting current frame to 172 will cause crash. It's related to sound. In VSE, 172 is the last frame of this sound strip:

Deleting it prevents crashing.

System Information
Windows-10-10.0.16299 64 Bits
GeForce GTX 1080/PCIe/SSE2 NVIDIA Corporation 4.5.0 NVIDIA 431.86

Blender Version
2.81 (sub 16), branch: master, commit date: 2019-11-15 16:32, hash: eba4a4bd73

I can confirm. It always crashes at frame 172. Not only when scrubbing, simply setting current frame to 172 will cause crash. It's related to sound. In VSE, 172 is the last frame of this sound strip: ![obraz.png](https://archive.blender.org/developer/F8127340/obraz.png) Deleting it prevents crashing. > **System Information** > Windows-10-10.0.16299 64 Bits > GeForce GTX 1080/PCIe/SSE2 NVIDIA Corporation 4.5.0 NVIDIA 431.86 > > **Blender Version** > 2.81 (sub 16), branch: master, commit date: 2019-11-15 16:32, hash: `eba4a4bd73`

Dalai Felinto commented

2019-11-18 20:07:54 +01:00

Added subscriber: @dfelinto

Dalai Felinto commented

2019-11-18 20:07:54 +01:00

Thanks for the report. Unfortunately the scenario described is still too time consuming for us to track down, we require the bug reporter to narrow down the problem by simplifying the .blend file.

Normally .blend files can be simplified by removing most objects and disabling settings, until the problem reveals itself more clearly. In your case you can delete not only objects bug also the strips that are not used, have a smaller video / sound, ...

Thanks for the report. Unfortunately the scenario described is still too time consuming for us to track down, we require the bug reporter to narrow down the problem by simplifying the .blend file. Normally .blend files can be simplified by removing most objects and disabling settings, until the problem reveals itself more clearly. In your case you can delete not only objects bug also the strips that are not used, have a smaller video / sound, ...

Marcin Twarowski commented

2019-11-20 10:21:29 +01:00

Here's a simplified file:
VSE_sound_crash.blend
All that's left is a single sound strip in the Video Sequence Editor. If you play animation it works fine. If you go to frame 172 or scrub past that frame, Blender will crash to desktop.

Here's a simplified file: [VSE_sound_crash.blend](https://archive.blender.org/developer/F8147157/VSE_sound_crash.blend) All that's left is a single sound strip in the Video Sequence Editor. If you play animation it works fine. If you go to frame 172 or scrub past that frame, Blender will crash to desktop.

Sybren A. Stüvel self-assigned this 2019-11-20 16:54:19 +01:00

Sybren A. Stüvel removed their assignment 2019-11-20 17:37:54 +01:00

Sybren A. Stüvel commented

2019-11-20 17:37:54 +01:00

Added subscribers: @neXyon, @dr.sybren

Sybren A. Stüvel commented

2019-11-20 17:37:55 +01:00

The cause of the crash is a careless cast from int64_t to int. The patch below fixes the crash and IMO is generally a better approach than the existing code, but the root cause probably lies somewhere else. I found that in SequenceHandle::updatePosition(float position) at frame 172 (the crashing frame), the position is 5.733313 where as m_end is 5.733333. This seems to suggest floating point errors are occurring somewhere.

diff --git a/extern/audaspace/plugins/ffmpeg/FFMPEGReader.cpp b/extern/audaspace/plugins/ffmpeg/FFMPEGReader.cpp
index 2da84ce0d4c..2f5b5bdd199 100644
--- a/extern/audaspace/plugins/ffmpeg/FFMPEGReader.cpp
+++ b/extern/audaspace/plugins/ffmpeg/FFMPEGReader.cpp
@@ -292,8 +292,8 @@ int FFMPEGReader::read_packet(void* opaque, uint8_t* buf, int buf_size)
 {
        FFMPEGReader* reader = reinterpret_cast<FFMPEGReader*>(opaque);
 
-       int size = std::min(buf_size, int(reader->m_membuffer->getSize() - reader->m_membufferpos));
-
+       int64_t remaining_buffer_size = reader->m_membuffer->getSize() - reader->m_membufferpos;
+       int64_t size = std::min(static_cast<int64_t>(buf_size), remaining_buffer_size);
        if(size < 0)
                return -1;

Probably @neXyon has a better grasp on this code ;-)

The cause of the crash is a careless cast from `int64_t` to `int`. The patch below fixes the crash and IMO is generally a better approach than the existing code, but the root cause probably lies somewhere else. I found that in `SequenceHandle::updatePosition(float position)` at frame 172 (the crashing frame), the position is 5.733313 where as `m_end` is 5.733333. This seems to suggest floating point errors are occurring somewhere. ``` diff --git a/extern/audaspace/plugins/ffmpeg/FFMPEGReader.cpp b/extern/audaspace/plugins/ffmpeg/FFMPEGReader.cpp index 2da84ce0d4c..2f5b5bdd199 100644 --- a/extern/audaspace/plugins/ffmpeg/FFMPEGReader.cpp +++ b/extern/audaspace/plugins/ffmpeg/FFMPEGReader.cpp @@ -292,8 +292,8 @@ int FFMPEGReader::read_packet(void* opaque, uint8_t* buf, int buf_size) { FFMPEGReader* reader = reinterpret_cast<FFMPEGReader*>(opaque); - int size = std::min(buf_size, int(reader->m_membuffer->getSize() - reader->m_membufferpos)); - + int64_t remaining_buffer_size = reader->m_membuffer->getSize() - reader->m_membufferpos; + int64_t size = std::min(static_cast<int64_t>(buf_size), remaining_buffer_size); if(size < 0) return -1; ``` Probably @neXyon has a better grasp on this code ;-)

blender-admin commented

2019-11-21 10:01:01 +01:00

This issue was referenced by 122ba774e0

This issue was referenced by 122ba774e024bca0819bbaa56cdfa3c47dd49f0a

Sybren A. Stüvel commented

2019-11-21 10:06:35 +01:00

Changed status from 'Open' to: 'Resolved'

Sybren A. Stüvel closed this issue

2019-11-21 10:06:35 +01:00

Sybren A. Stüvel self-assigned this 2019-11-21 10:06:35 +01:00

Sybren A. Stüvel commented

2019-11-21 10:07:20 +01:00

I've committed the above code, as it does fix the crash (and not crashing is better than crashing).

blender-admin commented

2019-11-22 10:34:01 +01:00

This issue was referenced by e93aa9c0fc

This issue was referenced by e93aa9c0fc669d0b09a1159e8ef1e2b9dfcc7320

Joerg Mueller commented

2019-11-22 10:40:29 +01:00

@dr.sybren nice find, thanks! I've also fixed this upstream. For consistency I'll also commit my fix to blender so that the audaspace code stays consistent. Less than 24 hours to review a patch, even though it's small, is not enough for a volunteer that is not full time employed to work on Blender. I usually only get to work on it during weekends and then not all of them are available either.

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

Blender Crashes Frequently with Timeline Scrub #71621