Crashes while trying to render viewport with cycles #81855

New Issue

Andrew Walsh · 2020-10-19T16:12:06+02:00

Andrew Walsh commented

2020-10-19 16:12:06 +02:00

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: 0330d1af29
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

**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: `0330d1af29` 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. ```lines 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 ```

Andrew Walsh commented

2020-10-19 16:12:06 +02:00

Added subscriber: @andywalshart

Andrew Walsh commented

2020-10-19 16:23:33 +02:00

**Confirmed that it does render ok in 2.83

kai commented

2020-10-19 17:07:28 +02:00

Added subscriber: @dsjasonh

kai commented

2020-10-19 17:07:28 +02:00

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

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 commented

2020-10-19 22:26:19 +02:00

Added subscriber: @rjg

Robert Guetzkow commented

2020-10-19 22:26:19 +02:00

Changed status from 'Needs Triage' to: 'Needs User Info'

Robert Guetzkow commented

2020-10-19 22:26:19 +02:00

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

Could you please test if this also happens in [2.91 ](https://builder.blender.org/download/)? 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). ![2019_12_04_upload_icon_developer_blender_org.png](https://archive.blender.org/developer/F8190038/2019_12_04_upload_icon_developer_blender_org.png)

Andrew Walsh commented

2020-10-20 11:13:53 +02:00

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

Philipp Oeser commented

2020-10-20 11:34:18 +02:00

Added subscriber: @lichtwerk

Philipp Oeser commented

2020-10-20 11:34:18 +02:00

Might be Embree related if it renders fine in 2.83?

Robert Guetzkow commented

2020-10-25 20:43:56 +01:00

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

Andrew Walsh commented

2020-10-25 22:48:46 +01:00

blender_system_info.txt

blender_debug_output.txt

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

[blender_system_info.txt](https://archive.blender.org/developer/F9092544/blender_system_info.txt) [blender_debug_output.txt](https://archive.blender.org/developer/F9092543/blender_debug_output.txt) 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

Robert Guetzkow commented

2020-10-25 23:21:11 +01:00

@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.)

@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 ](https://builder.blender.org/download/), 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.`)

Andrew Walsh commented

2020-11-01 13:06:43 +01:00

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

Robert Guetzkow commented

2020-11-01 13:24:49 +01:00

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

@andywalshart Please test **2.91** (can be downloaded [here ](https://builder.blender.org/download/)) 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.

Andrew Walsh commented

2020-11-01 14:24:14 +01:00

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.

Robert Guetzkow commented

2020-11-03 11:06:13 +01:00

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

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 commented

2020-11-03 11:14:14 +01:00

blender_system_info.txt

blender_debug_output.txt

[blender_system_info.txt](https://archive.blender.org/developer/F9180274/blender_system_info.txt) [blender_debug_output.txt](https://archive.blender.org/developer/F9180275/blender_debug_output.txt)

Robert Guetzkow commented

2020-11-03 11:37:36 +01:00

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

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

Andrew Walsh commented

2020-11-03 13:04:57 +01:00

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.

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 commented

2020-11-03 19:46:21 +01:00

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?

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 ](https://github.com/OpenImageIO/oiio/blob/1896caa37a0a2089e0735f874e44d0f4a6fbcb67/src/rla.imageio/rlainput.cpp#L687). 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?

Andrew Walsh commented

2020-11-03 21:48:37 +01:00

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.

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.

Robert Guetzkow commented

2020-11-03 22:38:48 +01:00

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

Andrew Walsh commented

2020-11-09 22:20:54 +01:00

blender_system_info.txt

blender_debug_output.txt

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.

[blender_system_info.txt](https://archive.blender.org/developer/F9247940/blender_system_info.txt) [blender_debug_output.txt](https://archive.blender.org/developer/F9247939/blender_debug_output.txt) 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.

Robert Guetzkow commented

2020-11-09 22:29:41 +01:00

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

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

Andrew Walsh commented

2020-11-10 00:21:02 +01:00

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

blender_system_info.txt

blender_debug_output.txt

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): [blender_system_info.txt](https://archive.blender.org/developer/F9248444/blender_system_info.txt) [blender_debug_output.txt](https://archive.blender.org/developer/F9248443/blender_debug_output.txt)

Andrew Walsh commented

2020-11-10 00:26:40 +01:00

projectName-new2.crash.txt

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.

[projectName-new2.crash.txt](https://archive.blender.org/developer/F9248477/projectName-new2.crash.txt) 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.

Robert Guetzkow commented

2020-11-10 09:59:32 +01:00

@andywalshart Thank you for the crash log. The issue this reports appears to be the same as #81685, #81102, which should be fixed by 6d8e03ddd9 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.

@andywalshart Thank you for the crash log. The issue this reports appears to be the same as #81685, #81102, which should be fixed by 6d8e03ddd9 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.

Robert Guetzkow commented

2020-11-10 10:05:28 +01:00

@andywalshart I will close this ticket for now as a duplicate of #81102. 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.

@andywalshart I will close this ticket for now as a duplicate of #81102. 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. ```

Robert Guetzkow commented

2020-11-10 10:05:53 +01:00

Closed as duplicate of #81102

Robert Guetzkow closed this issue

2020-11-10 10:05:53 +01:00

Andrew Walsh commented

2020-11-10 11:57:23 +01:00

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

Robert Guetzkow commented

2020-11-10 12:26:47 +01:00

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

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

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

Crashes while trying to render viewport with cycles #81855