Blender crashes on VSE zoom / scroll timeline sometimes #61043
Operating system: Windows 7 Professional 64 bit SP1
Graphics card: NVidia GeForce GT 630
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
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.
Note: This sounds similar to #53686 (VSE Render crash when zooming timeline)
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).
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.
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 :)
@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.
This issue was referenced by
Thanks for fix! I was as usual looking at wrong place...
No due date set.
No dependencies set.
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?