Cycles OSL - Changing rotation value in anisotropic shader crashes Blender #41870
Labels
No Label
Interest
Alembic
Interest
Animation & Rigging
Interest
Asset Browser
Interest
Asset Browser Project Overview
Interest
Audio
Interest
Automated Testing
Interest
Blender Asset Bundle
Interest
BlendFile
Interest
Collada
Interest
Compatibility
Interest
Compositing
Interest
Core
Interest
Cycles
Interest
Dependency Graph
Interest
Development Management
Interest
EEVEE
Interest
EEVEE & Viewport
Interest
Freestyle
Interest
Geometry Nodes
Interest
Grease Pencil
Interest
ID Management
Interest
Images & Movies
Interest
Import Export
Interest
Line Art
Interest
Masking
Interest
Metal
Interest
Modeling
Interest
Modifiers
Interest
Motion Tracking
Interest
Nodes & Physics
Interest
OpenGL
Interest
Overlay
Interest
Overrides
Interest
Performance
Interest
Physics
Interest
Pipeline, Assets & IO
Interest
Platforms, Builds & Tests
Interest
Python API
Interest
Render & Cycles
Interest
Render Pipeline
Interest
Sculpt, Paint & Texture
Interest
Text Editor
Interest
Translations
Interest
Triaging
Interest
Undo
Interest
USD
Interest
User Interface
Interest
UV Editing
Interest
VFX & Video
Interest
Video Sequencer
Interest
Virtual Reality
Interest
Vulkan
Interest
Wayland
Interest
Workbench
Interest: X11
Legacy
Blender 2.8 Project
Legacy
Milestone 1: Basic, Local Asset Browser
Legacy
OpenGL Error
Meta
Good First Issue
Meta
Papercut
Meta
Retrospective
Meta
Security
Module
Animation & Rigging
Module
Core
Module
Development Management
Module
EEVEE & Viewport
Module
Grease Pencil
Module
Modeling
Module
Nodes & Physics
Module
Pipeline, Assets & IO
Module
Platforms, Builds & Tests
Module
Python API
Module
Render & Cycles
Module
Sculpt, Paint & Texture
Module
Triaging
Module
User Interface
Module
VFX & Video
Platform
FreeBSD
Platform
Linux
Platform
macOS
Platform
Windows
Priority
High
Priority
Low
Priority
Normal
Priority
Unbreak Now!
Status
Archived
Status
Confirmed
Status
Duplicate
Status
Needs Info from Developers
Status
Needs Information from User
Status
Needs Triage
Status
Resolved
Type
Bug
Type
Design
Type
Known Issue
Type
Patch
Type
Report
Type
To Do
No Milestone
No project
No Assignees
8 Participants
Notifications
Due Date
No due date set.
Dependencies
No dependencies set.
Reference: blender/blender#41870
Loading…
Reference in New Issue
No description provided.
Delete Branch "%!s(<nil>)"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
System Information
MacOS 10.8.5, Nvidia GTX560
Blender Version
Broken: 2.71
d04e488
Exact steps for others to reproduce the error
aniso_osl_crash.blend
Console.log
aniso_osl_crash.crash.txt
Changed status to: 'Open'
Added subscriber: @SenHaerens
No crash for me. Tested on:
d04e488
d04e488
Added subscribers: @jensverwiebe, @Sergey
That's probably the same as #41526. Assuming that Jens experienced some weird bugs on osx which a currently worked around by different alignment, we might be doing something wrong..
@jensverwiebe, can you reproduce this crash btw?
Hi
1 I cannot reproduce this crash with attached .blend and Blender 2.71 neither actual master.
But: i see the reflection look different in 2.72dev !!!
Jens
Added subscriber: @ThomasDinges
Only seems to happen on my Mac Pro with 10.8.5.
Retina Macbook Pro with 10.9.4 doesn't crash like @ThomasDinges mentioned already.
Attached is the crash log from system console:
blender_2014-09-19-121843_spielberg.crash
Update: anisotropy changed in general from Blender 2.71 to 2.72.
@ senh: there may have been a bug in the former osl lib causing trouble, can guess several reasons.
As we have updated all osl stuff right now ( btw.: found even with dropped tbb in OIIO, OSL calcualtions are significant faster with the new combo ),
i plaid for just drop blender 2.71. I don't wanna go bugsearching inside previous libs.
Why Broken: 2.71
d04e488
btw. ? thats not official releaseJens
I'm a bit confused.
@SenHaerens, are you using builds from our buildbot?
@jensverwiebe, the original report says about 2.71
d04e488
, which is quite recent master branch, and presumably uses updated osl? Or you plan to update them again?...aaah, ic, my brain is adopted to 2.72 after testbuild already :P
Lemme check over with this perfectly new master, my was from yesterday, perhaps something introduced in between.
Jens
I'm compiling Blender locally by myself.
Attached is the system-info with build settings (OSL 1.5.10)
system-info.txt
Okay, made a few tweak twhich are useful anyway: all llvm and osl symbols are now local to prevent clashes.
@ senh: make sure the libs are uptodate when compiling pls.
Let's see further after ....
Jens
Thanks Jens, I'm gonna try it right away.
I'm updating the libs with svn update "lib/darwin-9.x.universal" That's ok, right?
The crash doesn't happen in official release Blender 2.71
9337574
btw.Jup, cd into lib/darwin-9.x.universal and svn update
Jens
d76d314
still crashing.Builded variation without OpenMP but that crashes also…
aniso_osl_crash.crash.txt
Dammit .... thats a nasty issue.
For i have no more 10.8 running here , must test on old machine with 10.6 now.
Also can you do a real debug build, the actual ctashlog is not detailed enough to dive into the underlaying problem.
Jens
On 10.6 i can reproduce this crash too.
From release build:
Thread 0 Crashed: Dispatch queue: com.apple.main-thread
0 libSystem.B.dylib 0x00007fff8459da6a __semwait_signal + 10
1 libSystem.B.dylib 0x00007fff845a1881 _pthread_cond_wait + 1286
2 org.blenderfoundation.blender 0x00000001035299ab boost::condition_variable::wait(boost::unique_lockboost::mutex&) + 75
3 org.blenderfoundation.blender 0x0000000100f3b355 ccl::TaskPool::cancel() + 85
4 org.blenderfoundation.blender 0x0000000100f224ba ccl::Session::reset_cpu(ccl::BufferParams&, int) + 170
5 org.blenderfoundation.blender 0x0000000100f23c6e ccl::Session::reset(ccl::BufferParams&, int) + 46
6 org.blenderfoundation.blender 0x0000000100f67d5f ccl::BlenderSession::synchronize() + 1967
7 org.blenderfoundation.blender 0x0000000100f5e485 ccl::sync_func(_object*, _object*) + 37
8 org.blenderfoundation.blender 0x0000000101b1e0cc PyEval_EvalFrameEx + 19948
9 org.blenderfoundation.blender 0x0000000101b21bff fast_function + 207
10 org.blenderfoundation.blender 0x0000000101b1ddae PyEval_EvalFrameEx + 19150
11 org.blenderfoundation.blender 0x0000000101b19124 PyEval_EvalCodeEx + 2356
12 org.blenderfoundation.blender 0x0000000101a92e85 function_call + 373
13 org.blenderfoundation.blender 0x0000000101a70997 PyObject_Call + 103
14 org.blenderfoundation.blender 0x0000000100afb05d bpy_class_call + 1069
15 org.blenderfoundation.blender 0x00000001006f32b1 engine_view_update + 113
16 org.blenderfoundation.blender 0x00000001002eca58 ED_render_scene_update + 312
17 org.blenderfoundation.blender 0x00000001007c94b3 DAG_ids_check_recalc + 147
18 org.blenderfoundation.blender 0x000000010089afcf BKE_scene_update_tagged + 719
19 org.blenderfoundation.blender 0x0000000100171c8d wm_event_do_notifiers + 1117
20 org.blenderfoundation.blender 0x000000010016e838 WM_main + 40
21 org.blenderfoundation.blender 0x000000010016a70a main + 1514
22 org.blenderfoundation.blender 0x0000000100001734 start + 52
..looks like a boost issue ... investigating....
Jens
crash log with debug build
d76d314
You misunderstood me, you also must run the debug build either from gdb or from withinxcode to get sensefull
debug info. Else we always get the same plain line.
Anyway, i fear i later have to even build osl as debug itself, thats a very odd problem. I assured everywhere we
have -mmacosx-version-min=10.6. OSL runs fine on 10.10 and 10.9, so somewhere this must have been ignored i guess.
It is also confusing that only changing this one parameter ("rotate" ) seems to cause a crash, it should crash always if the shader_eval would be broken.
This may take me a while to pin down ....
Jens
I think i found it, it's llvm having wrong looadcomands:
cmd LC_VERSION_MIN_MACOSX
Version must be 10.6, but atm the buildprocess refuses to take over my ( right used flags ), onit, stay tuned ...
Jens
All my attempts failed in between, the corrected llvm loadcommands are ok to get rid of, but are not the rootproblem.
Back to the workbench ...
Jens
I tried now all kinda tricks with the envolved libs. Nothing helped, this ugly beast must be
digged somewhere ( on OSX 10.8 debug i get a hint the desired object file is empty ?? ).
All in all after spending again hours in this, i had to decide to leave this as is in 2.72 release, unless
someone else wants look over it.
To me it looks like a compile bug in one of the dependencies.
so state for Blender 2.72 OSX now is:
Known bugs: "On OSX < 10.9, rendering with OSL crashes when the rotate value in anisotripic shaders != 0 or trying to set a value"
Jens
Is this issue still happening?
I've got feeling (from briefly trying decrypt the backtraces) root of this issues goes to the same issue as #42210. For until that one is fixed we can have heisen-crashes in OSL all the time :(
I can confirm it still crashes with build
d57ce42
(clang-omp-3.5 compiler)Tested same setup with the alignment fixes for osl.
Unfortunately the aniso crash on sytems < 10.9 still
happens. This seems nore like a buildsystem issue.
Cannot think of any other due the fact is:
No concrete finding was made for now, sorry.
Jens
Added subscriber: @brecht
Did you apply both the patch to OSL and change the Cycles code to specify 16 byte alignment in calls to
register_closure
?@jensverwiebe, is it stil an issue after latest OSL closure alignment and CPU thread safety commits?
@ sergey: afaik it is, due another problem in osl.
My guess is still something half done in osl building,
aka flags not working in some parts. No clue atm.
Jens
Can anyone reproduce this crash still with Blender 2.74?
To me it seems like this kind of crash can be caused by misaligned SSE access, but perhaps only on older CPUs, newer ones tend to handle misaligned SSE access better. The older OS X version may then not really make a difference, just if it is installed on a computer with an older CPU.
Blender 2.74 release (
000dfc0
) still broken here.Added subscriber: @btolputt
I cannot reproduce this on MacBook Pro (Retina, 15-inch, Mid 2014) running OSX 10.10.3
Added subscriber: @fjuhec
I can reproduce this with 2.75 RC on a 'Late 2007' Macbook model running 10.7.5
Happens as soon as Anisotropic rotation is changed when OSL is enabled or as soon as OSL is enabled if rotation was changed before.
If anyone is interested in giving me the steps to produce the needed output I can try.
This issue was referenced by
91b23992ce
Changed status from 'Open' to: 'Resolved'
This issue was referenced by
2dc4c07d3a
This issue was referenced by blender/cycles@098b81f2b5