Blender crashes on VSE zoom / scroll timeline sometimes #61043

New Issue

Adrian C. · 2019-01-31T02:24:27+01:00

Adrian C. commented

2019-01-31 02:24:27 +01:00

System Information
Operating system: Windows 7 Professional 64 bit SP1
Graphics card: NVidia GeForce GT 630

Blender Version
Broken: 2.80 Beta 64bit - a1ae04d15a (2019-01-29 22:41)
Worked: 2.79 (5bd8ac9 - 2017-09-11 10:43) - not sure about 32/64 bit

Short description of error
Blender crashes (simply dissapears) after some scrolling / zooming in video sequencer. No errors thrown.

Exact steps for others to reproduce the error
Please see attached blend file.

When working in Video mode, inside video sequencer area, Blender (more or less) randomly crashes on operations like scrolling the timeline (with middle mouse button), zoomin in or out in the timeline (with mouse wheel), even when pressing the Home button to zoom out full. It doesn't always happen after a precise amount of steps - sometimes all it takes is a single zoom out, other times you have to zoom in, scroll around a little, zoom out, etc. But, with the attached example, in less than a minute this bug can be reproduced.

Tipically, this bug occurs after i work on video editing for about 15 minutes or so, after i have around 30 strips or more (type doesn't matter, i have mixed audio, video and images). It's not a problem of memory, i have enough. Also, the window doesn't simply dissapears (as in becomes invisible with blender executable still runnning in background); no, the blender.exe is no longer running.

Also, i've taken the archive version of Blender from your website, i did not compile it myself (hence did not modify it).

If you need further informations, feel free to ask :)
Thank you verry much

crash.blend

system-info_2-80.txt

**System Information** Operating system: Windows 7 Professional 64 bit SP1 Graphics card: NVidia GeForce GT 630 **Blender Version** Broken: 2.80 Beta 64bit - a1ae04d15a9f (2019-01-29 22:41) Worked: 2.79 (5bd8ac9 - 2017-09-11 10:43) - not sure about 32/64 bit **Short description of error** Blender crashes (simply dissapears) after some scrolling / zooming in video sequencer. No errors thrown. **Exact steps for others to reproduce the error** Please see attached blend file. When working in Video mode, inside video sequencer area, Blender (more or less) randomly crashes on operations like scrolling the timeline (with middle mouse button), zoomin in or out in the timeline (with mouse wheel), even when pressing the Home button to zoom out full. It doesn't always happen after a precise amount of steps - sometimes all it takes is a single zoom out, other times you have to zoom in, scroll around a little, zoom out, etc. But, with the attached example, in less than a minute this bug can be reproduced. Tipically, this bug occurs after i work on video editing for about 15 minutes or so, after i have around 30 strips or more (type doesn't matter, i have mixed audio, video and images). It's not a problem of memory, i have enough. Also, the window doesn't simply dissapears (as in becomes invisible with blender executable still runnning in background); no, the blender.exe is no longer running. Also, i've taken the archive version of Blender from your website, i did not compile it myself (hence did not modify it). If you need further informations, feel free to ask :) Thank you verry much [crash.blend](https://archive.blender.org/developer/F6459506/crash.blend) [system-info_2-80.txt](https://archive.blender.org/developer/F6459537/system-info_2-80.txt)

Adrian C. commented

2019-01-31 02:24:27 +01:00

Added subscriber: @adrian.null

Richard Antalik commented

2019-01-31 09:20:16 +01:00

Added subscriber: @iss

Richard Antalik commented

2019-01-31 09:20:16 +01:00

Can you please run blender from command line with --debug argument and post output here? (or rather paste it there http://pasteall.org/ and link it here)
If it will produce a crash report it would be nice to include that also.

Can you please run blender from command line with --debug argument and post output here? (or rather paste it there http://pasteall.org/ and link it here) If it will produce a crash report it would be nice to include that also.

ChristopherAnderssarian commented

2019-01-31 21:33:53 +01:00

Added subscriber: @ChristopherAnderssarian

ChristopherAnderssarian commented

2019-01-31 21:33:53 +01:00

Note: This sounds similar to #53686 (VSE Render crash when zooming timeline)

Adrian C. commented

2019-01-31 23:12:07 +01:00

Hello everyone,
I've enabled "--debug" argument as asked, however surprise surprise ... Blender never crashed. I could finish a video i was working on, not one single problem.
I'm attaching the output here anyway, in case it helps somehow.
Since the crash seems to be memory related and i see the first line in debug output is "Switching to fully guarded memory allocator.", i'm guessing there's something about that that makes it not crash anymore while debugging.

Anyway, to still show you how it crashes, i've opened it again normally, i've opened the same project and i've attached Visual Studio debugger, while capturing my screen. I'm attaching several TXT files with details, including what assembler code was dissasembled from Visual Studio, and also posting a youtube link to that video. You can clearly see me perform just a couple of mousewheel up zooms and it crashes.

Oh, and regarding what @ChristopherAnderssarian said earlier - in my case i'm not rendering anything and it's also not related to text strips (i don't even have such in these projects).

blender_crash_windows_details.txt

blender_crash_message.txt

blender_crash_disassembly.txt

debugout_blender_nocrash.txt

https://youtu.be/mnJPvoTzCF8

Anyway, i'll use the "--debug" switch now as a workaround, thanks for pointing it out :) If i can still help you somehow, feel free to ask.

Cheers

Hello everyone, I've enabled "--debug" argument as asked, however surprise surprise ... Blender never crashed. I could finish a video i was working on, not one single problem. I'm attaching the output here anyway, in case it helps somehow. Since the crash seems to be memory related and i see the first line in debug output is "Switching to fully guarded memory allocator.", i'm guessing there's something about that that makes it not crash anymore while debugging. Anyway, to still show you how it crashes, i've opened it again normally, i've opened the same project and i've attached Visual Studio debugger, while capturing my screen. I'm attaching several TXT files with details, including what assembler code was dissasembled from Visual Studio, and also posting a youtube link to that video. You can clearly see me perform just a couple of mousewheel up zooms and it crashes. Oh, and regarding what @ChristopherAnderssarian said earlier - in my case i'm not rendering anything and it's also not related to text strips (i don't even have such in these projects). [blender_crash_windows_details.txt](https://archive.blender.org/developer/F6469063/blender_crash_windows_details.txt) [blender_crash_message.txt](https://archive.blender.org/developer/F6469064/blender_crash_message.txt) [blender_crash_disassembly.txt](https://archive.blender.org/developer/F6469065/blender_crash_disassembly.txt) [debugout_blender_nocrash.txt](https://archive.blender.org/developer/F6469067/debugout_blender_nocrash.txt) https://youtu.be/mnJPvoTzCF8 Anyway, i'll use the "--debug" switch now as a workaround, thanks for pointing it out :) If i can still help you somehow, feel free to ask. Cheers

Richard Antalik commented

2019-01-31 23:47:26 +01:00

I can confirm a frequent crash due to drawing sound waveform when strip has endstill frames. drawseqwave seems to be using length of strip to calculate data length

99.9% reproducible(I guess platform may play role) in my blend file. Just hit draw waveform.

code for creating waveform seems OK by just looking at it
I will have to look if something modifies waveform->length
This bug was probably present in 2.7 also as you can see artifacts of wrong data on end of waveforms when zoomed closely.

@adrian.null if you need to finish some work, either disable waveforms, or do cut some 10-50 frames from end of sound data and disable waveforms on this small strip, or change length by -1 to -5 so sound strip will not read to very end of data. this should prevent crashes.

Just a side note - I use sound strips a lot and never noticed this issue - it may be also codec issue - especially mp3 can report longer length of data stream then actual length. Such issue would be quite tricky to solve. By converting sounds to wave or flac format you may also eliminate this issue + as a bonus, waveforms will load faster :)

crash.blend

I can confirm a frequent crash due to drawing sound waveform when strip has endstill frames. `drawseqwave` seems to be using length of strip to calculate data length 99.9% reproducible(I guess platform may play role) in my blend file. Just hit draw waveform. code for creating waveform seems OK by just looking at it I will have to look if something modifies waveform->length This bug was probably present in 2.7 also as you can see artifacts of wrong data on end of waveforms when zoomed closely. @adrian.null if you need to finish some work, either disable waveforms, or do cut some 10-50 frames from end of sound data and disable waveforms on this small strip, or change length by -1 to -5 so sound strip will not read to very end of data. this should prevent crashes. Just a side note - I use sound strips a lot and never noticed this issue - it may be also codec issue - especially mp3 can report longer length of data stream then actual length. Such issue would be quite tricky to solve. By converting sounds to wave or flac format you may also eliminate this issue + as a bonus, waveforms will load faster :) [crash.blend](https://archive.blender.org/developer/F6469212/crash.blend)

Adrian C. commented

2019-01-31 23:55:24 +01:00

Thanks a lot for the info, now i understand :)

Richard Antalik commented

2019-01-31 23:58:09 +01:00

Added subscriber: @neXyon

Richard Antalik commented

2019-01-31 23:58:09 +01:00

@neXyon, not sure if you are involved in audio codec stuff, can you confirm my claim: "especially mp3 can report longer length of data stream then actual length." This is just a general observation from number of mp3 files, that behave this way.

blender-admin commented

2019-02-01 15:58:12 +01:00

This issue was referenced by d9d72cc9cb

This issue was referenced by d9d72cc9cba5db30d4104f8a5b5a867f72b6fbfe

Joerg Mueller commented

2019-02-01 15:58:52 +01:00

Changed status from 'Open' to: 'Resolved'

Joerg Mueller closed this issue

2019-02-01 15:58:52 +01:00

Joerg Mueller self-assigned this 2019-02-01 16:00:31 +01:00

Joerg Mueller commented

2019-02-01 16:00:31 +01:00

The bug was introduced in dbe23c5456, so it only exists in 2.8, not 2.7. And yes @iss I can confirm that, but it has nothing to do with this bug.

The bug was introduced in dbe23c5456, so it only exists in 2.8, not 2.7. And yes @iss I can confirm that, but it has nothing to do with this bug.

Richard Antalik commented

2019-02-01 16:14:43 +01:00

In #61043#611875, @neXyon wrote:
The bug was introduced in dbe23c5456, so it only exists in 2.8, not 2.7. And yes @iss I can confirm that, but it has nothing to do with this bug.

Thanks for fix! I was as usual looking at wrong place...

> In #61043#611875, @neXyon wrote: > The bug was introduced in dbe23c5456, so it only exists in 2.8, not 2.7. And yes @iss I can confirm that, but it has nothing to do with this bug. Thanks for fix! I was as usual looking at wrong place...

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 on VSE zoom / scroll timeline sometimes #61043