Page MenuHome

Crashes while trying to render viewport with cycles
Closed, DuplicatePublic

Description

System Information
Operating system: Windows-10-10.0.19041-SP0 64 Bits
Graphics card: GeForce GTX 1070/PCIe/SSE2 NVIDIA Corporation 4.5.0 NVIDIA 456.55

Blender Version
Broken: version: 2.90.0, branch: master, commit date: 2020-08-31 11:26, hash: rB0330d1af29c0
Worked: (newest version of Blender that worked as expected)

Short description of error
Crashes while trying to render viewport with cycles

Exact steps for others to reproduce the error
Hit the rendered viewport button using cycles and it'll crash. CPU or GPU. Been happening an awful lot with 2.9 and fairly often in 2.8. It's vague so I've just put off reporting it but now my scene won't render at all so I have no choice. Another common crash is when I close the render window - Blender goes down with it.

My scene is pretty enormous so it's hard to share.

blender.exe         :0x00007FF610A2C550  embree::avx2::TriangleMi<4>::loadTriangle
blender.exe         :0x00007FF6111B61C0  embree::avx::BVHNIntersector1<4,1,1,embree::avx::ArrayIntersector1<embree::avx::TriangleMiIntersect
blender.exe         :0x00007FF610CE25F0  embree::avx2::InstanceIntersector1::occluded
blender.exe         :0x00007FF610A31AA0  embree::avx2::BVHNIntersector1<4,1,0,embree::avx2::ArrayIntersector1<embree::avx2::InstanceIntersec
blender.exe         :0x00007FF6100D5400  rtcOccluded1
blender.exe         :0x00007FF60FF31EF0  ccl::shadow_blocked_transparent_all_loop
blender.exe         :0x00007FF60FEFCE00  ccl::kernel_branched_path_surface_connect_light
blender.exe         :0x00007FF60FF0A860  ccl::kernel_path_trace
blender.exe         :0x00007FF60FEB6280  ccl::kernel_cpu_avx2_path_trace
blender.exe         :0x00007FF60FBCA700  ccl::CPUDevice::render
blender.exe         :0x00007FF60FBCB590  ccl::CPUDevice::thread_render
blender.exe         :0x00007FF60FBCBA30  ccl::CPUDevice::thread_run
blender.exe         :0x00007FF60FBC60B0  std::_Func_impl_no_alloc<<lambda_d884e08a7877f415f05ce8ffda8f97b4>,void>::_Do_call
blender.exe         :0x00007FF61217F520  tbb::internal::function_task<std::function<void __cdecl(void)> >::execute
tbb.dll             :0x00007FFADFE137A0  tbb::recursive_mutex::scoped_lock::internal_try_acquire
tbb.dll             :0x00007FFADFE137A0  tbb::recursive_mutex::scoped_lock::internal_try_acquire
blender.exe         :0x00007FF60F93D010  tbb::internal::task_group_base::wait
blender.exe         :0x00007FF61217E720  ccl::TaskPool::wait_work
blender.exe         :0x00007FF60FFDBCC0  ccl::Session::run_cpu
blender.exe         :0x00007FF60FFDA620  ccl::Session::run
blender.exe         :0x00007FF6121831A0  ccl::thread::run
blender.exe         :0x00007FF60F791450  std::thread::_Invoke<std::tuple<void * __ptr64 (__cdecl*)(void * __ptr64),ccl::thread * __ptr64>,0,
ucrtbase.dll        :0x00007FFAF4C01430  configthreadlocale
KERNEL32.DLL        :0x00007FFAF6347020  BaseThreadInitThunk
ntdll.dll           :0x00007FFAF73FCEA0  RtlUserThreadStart

Event Timeline

**Confirmed that it does render ok in 2.83

Do u use Optix viewport denoise ? I also crash before, but I find out that every time when it crashes, I've turned the viewport denoise on and using Optix as the denoiser. BUT ! the cycles render engine is set to use CPU not GPU at first.
Since then, every time when I use viewport render, I check whether the denoise is on or not. if on, turn it off and change the cycles render from CPU to GPU first, and then, turn on optix viewport denoise. And it never crashes

Blender version 2.90.1

Robert Guetzkow (rjg) changed the task status from Needs Triage to Needs Information from User.EditedOct 19 2020, 10:26 PM

Could you please test if this also happens in 2.91? If yes, open Blender's installation directory and double click on the blender_debug_gpu.cmd. This will start Blender in debug mode and create log files. Try to make Blender crash again. Once it crashes the Windows Explorer should open and show you up to two files (debug log and system information). Add them to your bug report by clicking on the upload button as shown in the screenshot below. Please also upload the crash log located in C:\Users\[your username]\AppData\Local\Temp\[project name].crash.txt (or simply type %TEMP% into the path bar of the Windows Explorer).

Confirmed that it also crashes in 2.91 alpha both in viewport and regular render window. Rendering fine in 2.83. Just to emphasize, my scene was rendering fine for a good while, it just suddenly stopped being able to. But I have had a few random and sudden crashes during rendering in 2.9x

Might be Embree related if it renders fine in 2.83?

@Andrew Walsh (andywalshart) Please add the requested information to your report. We need them to investigate the problem.

Sorry I was really busy. Uploaded the log files but there isn't anything under: C:\Users\[your username]\AppData\Local\Temp\[project name].crash.txt

@Andrew Walsh (andywalshart) Thank you for the logs. Did Blender crash during the test? Just to avoid any confusion, you would have to replace the parts of the path in brackets with the actual user name or type %TEMP% into the Windows Explorer path bar. If you can please download 2.91, repeat the process and make sure that Blender crashes. The stack trace would be very helpful to identify to source of the issue.

There are two issues that I can spot:

  • You have invalid custom normals on at least one object (Invalid clnors in this fan!), but that shouldn't cause a crash
  • There is some issue with OpenImageIO that results in a failed assertion (E:\db18\build\S\VS1564R\build\openimageio\src\external_openimageio\src\rla.imageio\rlainput.cpp:688: struct OpenImageIO_v2_1::TypeDesc __cdecl OpenImageIO_v2_1::RLAInput::get_channel_typedesc(short,short): Assertion '!"Invalid colour channel type"' failed.)

just a quick update. Downloaded the 2.90.1 official release and upon clicking the cycles viewport render it insta-crashed.

Robert Guetzkow (rjg) added a comment.EditedNov 1 2020, 1:24 PM

@Andrew Walsh (andywalshart) Please test 2.91 (can be downloaded here) as instructed in the previous comments and provide the debug log and crash log for it. There was a bug in 2.90.1 that caused a crash when OptiX denoising was enabled.

oh, never mind, that was my confusion. I did test on 2.91 as instructed. I just thought that 2.91 was now released, so I tried on 2.90.1 this time. So yeah to confirm, I had also tested on 2.91 and it still crashed.

We would still need the crash log. Please start Blender in debug mode as instructed above and check the directory C:\Users\lordo\AppData\Local\Temp\.

@Andrew Walsh (andywalshart) We need the crash log [name of project].crash.txt file. If this occurs in a specific project file, please create a minimal version of it where the issue still happens, but everything irrelevant is removed (e.g. texture, other objects, ...).

My system doesn't save those files for some reason.

Could I request that you remove the title of the above text file as it's a project that's under NDA.

I'll have to decline providing the blender file because it would take me too long to trouble shoot which items I could remove. I'd bet that if I tripped it right back it would render fine. Plus it's all under NDA.

Robert Guetzkow (rjg) added a comment.EditedNov 3 2020, 7:46 PM

Unfortunately, then we can't really help. The fact that Blender doesn't produce a crash log on your system might be caused by the assert happening in OpenImageIO. All I can tell from your current log files is that at some point, some image in your project makes OpenImageIO trip over an assert in RLAInput::get_channel_typedesc. Presumably that means a broken/corrupted image file or a case that OpenImageIO doesn't handle properly. It may also be caused by how Blender uses OpenImageIO, but we can't really tell without a stack trace or being able to reproduce the issue on our computers. Does that help you narrow it down?

Do you think it's worth maybe saving incrementally and noting any new assets imported between increments? I have this happen all the time and if I had to guess, I'd say it was after importing a model.

One theory that stands out, if it's image related, I did import some assets with DDS files as image textures. Not sure if that file format causes problems.

@Andrew Walsh (andywalshart) That would be a good strategy if you suspect this is caused by the assets being imported. If you could check if this occurs after importing the assets with a DDS textures, that would already be a good start.

Just had another crash in 2.90 and wanted to run the logs past you just in case it was something different. I felt like this scene should have been a bit more stable for some reason. Crashed while activating cycles in viewport.

@Andrew Walsh (andywalshart) The debug log reports that it wrote a crash log (C:\Users\lordo\AppData\Local\Temp\[project name].crash.txt). Please upload it as well. Seems like loading the debug symbols failed in the last one, so there probably isn't anything in there. If you can repeat the crash in 2.90.1 or later and it writes the crash log properly with a strack trace, then this would be very useful.

Not sure what the above means but it crashed again. Although I will say that I didn't start Blender with the blender_debug_gpu.cmd, I started it with blender_debug_log.cmd because I was expecting a non-gpu related crash. But just in case, here are the files (this is 2.90.1):

Think this might be relevant too. Sorry. I'm crashing so many times I'm not sure if all these text files relate to the same crash. I think they do.

@Andrew Walsh (andywalshart) Thank you for the crash log. The issue this reports appears to be the same as T81685, T81102, which should be fixed by rB6d8e03ddd991a390fb6bbc3277991b0272142c21 in Blender 2.91.0 and 2.92.0. There is also no mention of the OpenImageIO error that was in your previous report so these seem unrelated.

@Andrew Walsh (andywalshart) I will close this ticket for now as a duplicate of T81102. If you find a way to reproduce the OpenColorIO error, e.g. through a particular texture that causes the problem, then please create a new report as the two issues are unrelated. You can identifies this error by the following line in the debug log.

E:\db18\build\S\VS1564R\build\openimageio\src\external_openimageio\src\rla.imageio\rlainput.cpp:688: struct OpenImageIO_v2_1::TypeDesc __cdecl OpenImageIO_v2_1::RLAInput::get_channel_typedesc(short,short): Assertion '!"Invalid colour channel type"' failed.

Quick question while I look through debug logs. Is it fairly normal for the text file to be hundreds of megabytes?

@Andrew Walsh (andywalshart) Well, it depends on the debug flags used. The --debug-gpu option from blender_debug_gpu.cmd does produce a lot of output and is therefore mostly used for short tests to reproduce a specific known problem. Additionally, you still have the incorrect custom normals in your file, which get reported very often.