Page MenuHome

Blender crashes on render when OSL script uses more than two textures
Closed, InvalidPublic


System Information
Windows 8.1 64-bit and GeForce GT 735 M (Sony VAIO SVF 15A)

Blender Version
Broken: 2.71 9337574, (official 2) and 2.71 5588e45 (latest Windows x64 buildbot version)
Worked: (I don't know of any)

Problem Description
When attempting to use an Open Shading Language script that loads more than two textures, blender crashes immediately upon beginning a render (viewport or not). The OSL shader will successfully compile, but attempting to use it causes a crash.

Crashes only occur if more than two textures contribute to the output of the script; if a texture is included in the code but not used, the script can be used without crashing.

The problem does not appear to be the combined size of the textures; a single 868 kb texture loads perfectly while three 3.63 kb textures cause a crash.

The problem does not appear to be a limited number of textures accessible by all OSL scripts in a .blend file that are contributing to a material; using multiple scripts and choosing different textures to output does not cause a crash, so long as no more than two textures are used by any individual script.

Exact steps for others to reproduce the error
A .blend file containing an example of such a problematic script is included; the .zip file contains the Textures folder that is referred to in the script. To get the OSL script in the .blend file to run without modification, extract the .zip file so that 0.png, 1.png, and 2.png are located in C:\Textures\. But the script node has a field for entering the data path, which can be changed to point to any directory you'd like, so you don't need to put them where I did in my example.

An example OSL script should be open in a text window when the .blend file is opened: the script is included below, with an additional comment describing what to change to cause the crash:

#include "stdosl.h"

shader Multitexture(

string Folder = "C:/Textures/",
output color Stamp = 0)


float x1 = P[0];
float y1 = -P[1];
color Number = texture(concat(Folder,"0.png"),x1,y1);
color Number1 = texture(concat(Folder,"1.png"),x1-1.0,y1);
color Number2 = texture(concat(Folder,"2.png"),x1-2.0,y1);
color total = Number+Number1+0*Number2;

// Change the above line to "color total = Number+Number1+Number2;" (remove the 0*) and click "script node update" and then try a viewport render in the 3D view window to the right of the text window. For me, Blender crashes.

Stamp = total;


Event Timeline

Tom Benedett (moak) raised the priority of this task from to 90.
Tom Benedett (moak) updated the task description. (Show Details)
Tom Benedett (moak) edited a custom field.

I thought I didn't have any older versions to compare to, but it turns out that I did:

Blender 2.69 - revision e5aaa9d, from 2013/12/25, is able to load at least four different textures without crashing (I did not find an upper limit). So this did work in the past.

Blender 2.70a official (f93bc76, 2014/4/10) also works.

Thomas Dinges (dingto) lowered the priority of this task from 90 to Normal.Jun 30 2014, 11:38 AM

I can't really reroduce the crash nether on windows nor on linux. Did you try loading factory settings before tests?

I cannot get it to crash either, all 3 textures are rendered. (Windows 7 x64, 0b5fda5)

I didn't think that any relevant settings were changed from factory settings, but after trying that, it still crashes.

I will try it again on another computer when I have access to it later this week.

Okay, the latest Windows 64-bit Buildbot version (fedbb88) still crashes (even with factory settings loaded) on the computer on which I first observed this behavior, but on my main Blender station, a Windows 7 64-bit desktop with a GTX 580 GPU, the same Blender version under the same conditions does not crash.

I don't think this is a problem that will bother me again, so do what you will with this bug report.

Sergey Sharybin (sergey) changed the task status from Unknown Status to Unknown Status.Jul 4 2014, 12:03 PM

Well, the thing is -- in order to be able to fix an issue we need to be able to reproduce it first. Since you can not reproduce it on another computer it's likely something up to the local settings on the machine with an issue.

If you manage to find steps how to reproduce the crash on your another computer then please let us know, likely them we'll be able to reproduce as well.

For until then i'm archiving the report. Please share info here if you have news!