Page MenuHome

Crash with smoke
Closed, ArchivedPublic

Description

System Information
Operating system: Windows 10
Graphics card: Nvidia 1070 GTX

Blender Version
Broken: blender-2.80.0-git.191b8951f7af-windows64
Worked: (optional)

Short description of error
Moving to the next frame on the timeline causes blender to crash.

Exact steps for others to reproduce the error
I open

(which has a baked smoke sim on my machine), Z -> rendered, then move to the timeline and Right arrow. Boom.

This is my first bug submission on this project, let me know if I should provide other information, etc. Thanks!

Details

Type
Bug

Event Timeline

Forgot the full system info if needed.

Cannot reproduce here.
First I thought it was a duplicate of T58471 (but now I cannot reproduce that other report either anymore...)

I can't reproduce it either..

@Fred Gobry (chbug), can you reproduce this issue in new files as well?
Maybe also try a newer Blender version.

If you have access to another computer, you can also try it there to see if this problem is specific to your computer.

Sebastian Parborg (zeddb) triaged this task as Needs Information from User priority.Feb 11 2019, 3:34 PM

I'll try to reproduce with an even more recent build than 0208, which is the version I also used to create the sample file. Also I'll try to discard the cache and bake again. If it turns out it's related to the baked data, is there a simple way to share the 30GB of cached data, or is it even worth it?

I can still reproduce it with Blender 2.80 rel. 2019/02/13. I can also reproduce it by discarding the baked files and regenerating them. When you attempted to reproduce, did you bake the smoke sim?

I can try to start with a fresh file, but given that baking takes 20 minutes, I might get lucky but if I need to fiddle with lots of parameters it might take a long time to set things up the same way. Given that the failing file was generated with rel. 2019/02/08, is there a solid reason to expect it to be any different anyways?

Alternatively, if you have pointers on how to extract a stack trace of the crash on a windows machine, I can try to do that. I'm more familiar with development on linux systems, but my beefier machine runs Windows.

Fred Gobry (chbug) raised the priority of this task from Needs Information from User to Needs Triage by Developer.Feb 16 2019, 11:23 PM
Sebastian Parborg (zeddb) triaged this task as Needs Information from User priority.

Does it not crash if you download this dll and copy it so its located in the same directory as 'blender.exe' and run Blender normally?

Fred Gobry (chbug) raised the priority of this task from Needs Information from User to Needs Triage by Developer.Feb 25 2019, 2:40 AM

Same crash with the DLL (and blender being super slow before that, which was expected I guess).

Yes, that .dll forces blender to use software rendering. So now we know that this isn't an issue with your GPU drivers at least.

I can't reproduce this even if I bake the simulation, yes. It doesn't seem to crash when I move around the timeline in rendered mode.

Because it seems like none of the devs can reproduce this, can you see if you can reproduce this issue from scratch with a build from today?

Sebastian Parborg (zeddb) triaged this task as Needs Information from User priority.Feb 25 2019, 2:53 PM
Fred Gobry (chbug) raised the priority of this task from Needs Information from User to Needs Triage by Developer.Mar 7 2019, 6:36 AM

Reproduced from scratch from today's build (see

). You need to bake the sim, switch to rendered mode, and use Shift-Left & Shift-Right to jump in the timeline (with this file it wasn't enough to Shift-Right).

Also, I installed the dev environment and can provide full stack traces if it helps.

Philipp Oeser (lichtwerk) triaged this task as Needs Information from User priority.May 3 2019, 12:36 PM

Also cannot reproduce here...

@Fred Gobry (chbug): did you have success getting a full stack trace?

Bastien Montagne (mont29) closed this task as Archived.
Bastien Montagne (mont29) claimed this task.

More than a week without reply or activity. Due to the policy of the tracker archiving for until required info/data are provided.