System Information
OSX 10.6.8
Graphic card ATI Radeon HD2600 Pro
iMa8,1
Intel Core 2 Duo
Blender Version
Broken: 2.71 of date 07-18-14 Hash # a04a803
Go to node window, add material, add mix shader in between diffuse and output,
add transparent to mix,
Open materials panel, crash.
See unlisted vid: http://youtu.be/1QGv5fccUrs
Blend precrash attached as well as crash report.
Can’t confirm it either here (latest master, linux64, NVidia 850m). Maybe OSX-related?
My Windows 8.1 version works okay using the latest build e0d8e62 of Jul 19.
So must be a Mac thing. Crashes on my OSX 10.6.8 older mac, and the newer 2011 OSX 10.9.3 one as well.
Confirmed here.
The key point is you have OSL enabled. Showing the material panel initiates a preview render (even for the small icon in front of the material name) the crash can also be achieved with 3dview or final render.
Disable OSL and setup your example with 3dview rendering - all is ok
Enable OSL and crash.
I found the same issue running osl scripts that mix closures, while plain colour and numeric output is ok.
2.71-release is good, it is just recent master that fails.
A gdb backtrace from the example diffuse and transparent into mix shows it fails inside flatten_surface_closure_tree.
Program received signal SIGBUS, Bus error.
[Switching to Thread 8269bf800 (LWP 101314)]
0x0000000001f532e4 in ccl::flatten_surface_closure_tree(ccl::ShaderData*, int, OSL::ClosureColor const*, ccl::float3)
()
(gdb) bt
#0 0x0000000001f532e4 in ccl::flatten_surface_closure_tree(ccl::ShaderData*, int, OSL::ClosureColor const*, ccl::float3) ()
#1 0x0000000001f53240 in ccl::flatten_surface_closure_tree(ccl::ShaderData*, int, OSL::ClosureColor const*, ccl::float3) ()
#2 0x0000000001f53240 in ccl::flatten_surface_closure_tree(ccl::ShaderData*, int, OSL::ClosureColor const*, ccl::float3) ()
#3 0x0000000001d7ab3c in ccl::kernel_path_integrate ()
#4 0x0000000001c1420a in ccl::kernel_cpu_avx_path_trace(ccl::KernelGlobals*, float*, unsigned int*, int, int, int, int, int) ()
#5 0x0000000001711450 in ccl::CPUDevice::thread_path_trace(ccl::DeviceTask&) ()
#6 0x000000000168ed5c in boost::function0<void>::operator()() const ()
#7 0x0000000001f60b0d in ccl::TaskScheduler::thread_run(int) ()
#8 0x000000000168ed5c in boost::function0<void>::operator()() const ()
#9 0x00000000016f9649 in ccl::thread::run(void*) ()
#10 0x00000008055ae192 in ?? () from /lib/libthr.so.3@Shane Ambler (sambler), what's your CPU?
Also, does the crahs happen when switching viewport to a rendered mode instead of going to the material panel?
It seems crash for is caused by some bad memory access in OSL's evaluation function, not really up to investigating this further for until new OSL/LLVM are committed to SVN libraries repository. It might be some issue with optimization or so.
@Thomas Dinges (dingto), @Martijn Berger (juicyfruit), any idea when we'll have new OSL? :)
Also we have one report about OSL crash, will merge them together since root of the issue is likely goes to the same exact thing.
I found a cause for this. I am re-opening this issue as I can't reproduce a crash with the example in the other issue T40971 - environment maps with osl, so I can't be sure they are related.
rB85c7fce3de9821de6e806fe057f762577e01ad06 specifically in the ShaderClosure struct definition it moved data2 before N and T. Moving data2 after T fixes this for me.
So that's a subtle thing that points to a deeper issue that needs further investigation.
For now the workaround is -
diff --git a/intern/cycles/kernel/kernel_types.h b/intern/cycles/kernel/kernel_types.h index 164df41..a506d4a 100644 --- a/intern/cycles/kernel/kernel_types.h +++ b/intern/cycles/kernel/kernel_types.h @@ -528,11 +528,10 @@ typedef struct ShaderClosure { float data0; float data1; - float data2; float3 N; float3 T; +float data2; #ifdef __OSL__ void *prim; #endif
Confirmed, the workaround above fixes the OSL crash with bmw file on Mac OS as well. @jens verwiebe (jensverwiebe)