Page MenuHome

Cryptomatte Pass rendering crashes Blender if 'Accurate Mode' is unchecked and 'Material' pass is selected
Closed, ResolvedPublic

Description

System Information
Windows 10, Quadro 4000

Blender Version
Broken: 0e268fb68b612e44a74a74631df206c8aaded97b (compiled an hour ago)

Short description of error
Cryptomatte rendering works fine if 'Accurate Mode' is enabled and the Material Cryptomatte Pass is checked. As soon as 'Accurate Mode' it is disabled, Blender closes immediately when starting a rendering with F12. It is worth noting that I was not able to reproduce this every time. Sometimes I had to render twice or three times to have Blender Crash.

The output in the Console is:

Windows fatal exception: access violation

Thread 0x0000395cWindows fatal exception: access violation

Windows fatal exception: access violation

Windows fatal exception: Error   : EXCEPTION_ACCESS_VIOLATION
access violationAddress : 0x00007FF697CE3EC4


Error   : EXCEPTION_ACCESS_VIOLATION
Windows fatal exception: Address : 0x00007FF697CE3EC4
Module  : C:\blender-git\build_windows_Full_x64_vc15_Release\bin\Release\blender.exe
access violation

Exact steps for others to reproduce the error

  • Start Blender with Factory Settings
  • Use Cycles as Render Engine
  • In the Passes Tab, enable 'Material' Cryptomatte Pass
  • In the same tab, uncheck 'Accurate Mode'
  • Hit F12 -> Crash

Details

Type
Bug

Event Timeline

Brecht Van Lommel (brecht) lowered the priority of this task from Needs Triage by Developer to Confirmed, Medium.Oct 29 2018, 10:47 AM
# backtrace
/home/brecht/dev/build_linux/bin/blender(BLI_system_backtrace+0x33) [0x55df5b0fb4b3]
/home/brecht/dev/build_linux/bin/blender(+0x1688ae6) [0x55df5a66eae6]
/lib/x86_64-linux-gnu/libc.so.6(+0x3ef20) [0x7f0076886f20]
/home/brecht/dev/build_linux/bin/blender(std::__detail::_Map_base<float, std::pair<float const, float>, std::allocator<std::pair<float const, float> >, std::__detail::_Select1st, std::equal_to<float>, std::hash<float>, std::__detail::_Mod_range_hashing, std::__detail::_Default_ranged_hash, std::__detail::_Prime_rehash_policy, std::__detail::_Hashtable_traits<false, false, true>, true>::operator[](float const&)+0x5c) [0x55df5b6e151c]
/home/brecht/dev/build_linux/bin/blender(+0x26eb15d) [0x55df5b6d115d]
/home/brecht/dev/build_linux/bin/blender(ccl::CPUDevice::thread_render(ccl::DeviceTask&)+0xb3a) [0x55df5b49e62a]
/home/brecht/dev/build_linux/bin/blender(ccl::TaskScheduler::thread_run(int)+0x93) [0x55df5b85be13]
/home/brecht/dev/build_linux/bin/blender(ccl::thread::run(void*)+0xe) [0x55df5b85dbee]
/usr/lib/x86_64-linux-gnu/libstdc++.so.6(+0xbd57f) [0x7f0075fb457f]
/lib/x86_64-linux-gnu/libpthread.so.0(+0x76db) [0x7f00780a06db]
/lib/x86_64-linux-gnu/libc.so.6(clone+0x3f) [0x7f007696988f]

I've got the feeling that commit 5e121c8eab23d3d42745277f9c92617cb0aeb066 by Stefan Werner has resolved this issue. So far I had no more crashes.

Indeed appears to be solved.