Page MenuHome
Create Task
Maniphest T54887

OSL: Cycles Script Node with trace call crashes Blender on render
Closed, ResolvedPublic
Actions

Description

System Information
Windows 10 64 bit, GTX 980 Ti, rendering on i9-7900X

Blender Version
Broken:
2.75a c27589e
2.78c e92f235283
2.79b f4dc9f9d68b
2.79 5740505 (latest build)
2.79 60f4cb2 (latest build, win32)
2.80 cfa1700 (latest build)

Worked:
2.70 19e627c

Short description of error
A trivial OSL Script Node in Cycles where trace(a, b) and then getmessage("trace", hitdist", dist) is called and result is passed to mix node crashes Blender with EXCEPTION_ACCESS_VIOLATION on render. I experienced similar crashes even when trace/getmessage weren't being called, but this particular example was easiest to reproduce consistently.

Exact steps for others to reproduce the error

osl-bug.blend486 KBDownload

Open attached .blend file, switch to rendered viewport shading or hit render to instantly crash Blender.

Related Objects

Event Timeline

Tim (ptim) created this task.Apr 29 2018, 7:17 PM
Philipp Oeser (lichtwerk) added a subscriber: Philipp Oeser (lichtwerk).Apr 30 2018, 11:20 AM

Cannot reproduce here (checked official releases 2.79, 2.79a, 2.79b, 2.78c), but I'm on linux...
Someone on Windows being able to reproduce?

Christopher_Anderssarian added a project: Cycles.Apr 30 2018, 11:32 AM
Christopher_Anderssarian added a subscriber: Christopher_Anderssarian.

Cannot reproduce on 5960x CPU with 2.79a/b on Windows 7.

Through author probably used their GTX 980 Ti.

Philipp Oeser (lichtwerk) added a comment.Apr 30 2018, 11:41 AM

@Christopher_Anderssarian : thx for testing.
OSL is CPU only afaik.

Christopher_Anderssarian added a comment.Apr 30 2018, 2:25 PM

dufff.....
Shows I don't have experience with GPU Rendering....

Tim (ptim) updated the task description. (Show Details)Apr 30 2018, 2:59 PM
Tim (ptim) added a comment.Apr 30 2018, 5:17 PM

The full error message is:

LLVM ERROR: Cannot select: 0x18cf82f1080: f32 = X86ISD::FSETCCss 0x18cf82f79e0, 0x18cf82f1880, 0x18cf82f1280 [ORD=89] [ID=38]
  0x18cf82f79e0: f32 = X86ISD::FMIN 0x18cf82f81f0, 0x18cf82f1780 [ORD=87] [ID=37]
    0x18cf82f81f0: f32,ch = load 0x18cf348cc88, 0x18cf82f7ff0, 0x18cf34244f0<LD4[ConstantPool]> [ID=31]
      0x18cf82f7ff0: i64 = X86ISD::Wrapper 0x18cf34245f0 [ID=19]
        0x18cf34245f0: i64 = TargetConstantPool<float 1.000000e+00> 0 [ID=13]
      0x18cf34244f0: i64 = undef [ID=3]
    0x18cf82f1780: f32,ch = load 0x18cf348cc88, 0x18cf3422fd0, 0x18cf34244f0<LD4[%sunkaddr8]> [ORD=85] [ID=36]
      0x18cf3422fd0: i64 = add 0x18cf34231d0, 0x18cf3424af0 [ORD=83] [ID=30]
        0x18cf34231d0: i64,ch = CopyFromReg 0x18cf348cc88, 0x18cf82f70e0 [ORD=82] [ID=18]
          0x18cf82f70e0: i64 = Register %vreg3 [ID=1]
        0x18cf3424af0: i64 = Constant<8> [ID=2]
      0x18cf34244f0: i64 = undef [ID=3]
  0x18cf82f1880: f32 = ConstantFP<0.000000e+00> [ID=4]
  0x18cf82f1280: i8 = Constant<6> [ID=12]
In function: node_mix_0000018CBF9EAF70_10
Error: EXCEPTION_ACCESS_VIOLATION

Whether the script works or crashes seems to depend on what its output is connected to. I tested a few different cases, I can reproduce these results 100% of the time:

Crashes:
Output of the Script node connected to Fac of MixRGB node, when Color1 != Color2. (see: the attached .blend file in original post)
Output of the Script node connected to Fac of Mix Shader node.
Output of the Script node connected to Saturation of Hue/Saturation Node.

Works:
Output of the Script node connected to Fac of MixRGB node, when Color1 == Color2. (I guess the entire node is optimized away in this case?)
Output of the Script node connected to Strength of Emission node.
Output of the Script node connected to Hue of Hue/Saturation Node.

Ray Molenkamp (LazyDodo) lowered the priority of this task from 90 to 30.Oct 10 2018, 4:53 PM
Ray Molenkamp (LazyDodo) added a subscriber: Ray Molenkamp (LazyDodo).

we have recently updated osl/llvm, is this still an issue? @Tim (ptim) can you check with a nightly build?

Tim (ptim) added a comment.Oct 10 2018, 5:10 PM

Thank you, this issue seems to be resolved as of 76f640c27d8.

Ray Molenkamp (LazyDodo) changed the task status from Unknown Status to Resolved.Oct 10 2018, 5:20 PM
Ray Molenkamp (LazyDodo) claimed this task.

Score! thanks for the quick test!