Page MenuHome

Blender Crashes Frequently with Timeline Scrub
Closed, ResolvedPublic


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: rBf6cb5f54494e
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

  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:

  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.

Event Timeline

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: rBeba4a4bd73ba

Dalai Felinto (dfelinto) lowered the priority of this task from Needs Triage by Developer to Needs Information from User.Mon, Nov 18, 8:07 PM

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, ...

Here's a simplified file:

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.

Philipp Oeser (lichtwerk) raised the priority of this task from Needs Information from User to Waiting for Developer to Reproduce.Wed, Nov 20, 10:39 AM

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 @Joerg Mueller (nexyon) has a better grasp on this code ;-)

Sybren A. Stüvel (sybren) lowered the priority of this task from Waiting for Developer to Reproduce to Confirmed, Medium.Wed, Nov 20, 5:38 PM

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

@Sybren A. Stüvel (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.