Page MenuHome

Blender / Cycles / Material list Crash - When dealing with image sequences longer than 63 images long on Windows
Closed, ResolvedPublic


Edited to refine the crash problem

System Information
Windows 7 x64 GTX 1080, core i7 920

Blender Version
Broken: 411836d through to f7eaaf3
Worked: e9689e1

Short description of error
Image sequences part of a material which have more then 63 images in the folder crashes out blender on windows

Extract zip file, open materialListCrash3.blend, go into the material tab, and list materials

Video of the crash --

Doesnt matter if JPG or PNG images. both will cause a crash
if you delete one image out from the animatedBillboard folder, it will work fine.

Extra tests, all give out crashes.
Removing all system prefs
Factory settings
Server machine, raw win7 install with only blender drivers installed
Multiple artist machines.

Event Timeline

Deleting the next shader in the blend file (not by name) via python ([60].user_clear() ) fixed the crash... However, importing the offending shader into a new blend file seemed not crash that blender out. The offending material was only two nodes, a diffuse shader and a output node.

Doing some more tests now.

EDIT: Didnt fix the crash :(, i think there are two lots of crashes going on rather than just one. Both to do with the material icon generation.

These things are difficult to test without a test scene.
Can you reproduce the case on a simpler scene?

Also what is the amount of RAM in your system?

This is one of the crashes. Managed to simplify it down to one material. But I cant seem to replicate it totally, as when the link is totally broken it doesnt crash.

Removing the animated image seems to fix the crash. The file path is correct and pointing to a valid image, if i view the image in the image editor first then load up the material list it seems to work fine.

This is a windows computer with network drives mapped to the Z / Y / X locations.

RAM is fine, 16gb on the host, 8gb on the gpu

Second crash was also from an animated texture. This one was relatively referenced instead of absolutely. Not sure if that makes a difference

Ok so deleting those two materials out of the scene does fix the material list crashing.

There seems to be a problem with loading up animated image textures.

Could be because we are looping the textures, or loading them up off a slightly latent device (network disks).

Bastien Montagne (mont29) lowered the priority of this task from 90 to 30.Feb 10 2017, 10:50 AM

No crash here, but then, do not have the images… can you please embed the crashing sequence in the .blend?

The images are not the problem but more how they are loaded up.

It is a PNG image sequence, and probably wont be able to provide either of them. one had an alpha channel one did not

Loading up the image file directly in the UV/Image editor first allowed it to work correctly.

I will try and replicate the issue tomorrow.

I have tried to replicate on linux and unable.. will try windows tomorrow.

Managed to replicate under windows. Has to do with image sequences larger then 63 images long

Doesnt matter if JPG or PNG images. both will cause a crash

Extract zip file, open materialListCrash3.blend, go into the material tab, and list materials

if you delete one image out from the animatedBillboard folder, it will work fine.

Carlo Andreacchio (candreacchio) renamed this task from Blender / Cycles / Material list Crash to Blender / Cycles / Material list Crash - When dealing with image sequences longer than 63 images long on Windows.Feb 11 2017, 1:33 AM

With latest buildbot ( 38155c7 ) win64 , did i miss anything?

edit: not sure why but video won't play, here's a youtube link

yeh i just downloaded it manually and watched.

So my system crashes out at around the 5 second mark when it is generating the icon for the material list.

Are you running windows 7? maybe it is a OS issue?

ill download a screen recorder.....

If i delete one file out of that folder it doesnt crash

system info txt file here --

Tried clearing my user prefs and that didnt fix it either.

try running "blender.exe --factory-startup"

try running "blender.exe --factory-startup"


Could be because of this commit? b047d79 --, fits into the right timeline.

We dont build our own blenders, otherwise I would help out finding the exact commit.

Could be anything really, but unless we can reproduce the issue it'll be very hard to point a finger at something.

I just tried it on one of our server machines running the stock windows 7 (no upgrades, nothing else installed apart from blender / drivers / windows 7 (no sp1)), crash on that aswell.

core i7 860 gtx 1080.

Ray molenkamp (LazyDodo) raised the priority of this task from 30 to 50.Feb 11 2017, 5:25 AM

Yup was able to repro it on a clean win7 VM, but not with a debug build, so feels like a race condition somewhere

Can you try to start Blender with -t 1 option (from command line), and see if crash still happens? This should disable multi-threading, and tell us whether it’s a causing the problem or not.

-t 1 doesen't help , but i was able to grab a stack trace

 	blender.exe!memcpy() Line 128	Unknown
 	0000000000000004()	Unknown
 	00000000000e1000()	Unknown
>	blender.exe!ccl::BlenderSession::builtin_image_pixels(const std::basic_string<char,std::char_traits<char>,std::allocator<char> > & builtin_name, void * builtin_data, unsigned char * pixels, const unsigned __int64 pixels_size) Line 1170	C++
 	blender.exe!ccl::ImageManager::file_load_image<2,unsigned char,unsigned char>(ccl::ImageManager::Image * img, ccl::ImageManager::ImageDataType type, int texture_limit, ccl::device_vector<unsigned char> & tex_img) Line 552	C++
 	blender.exe!ccl::ImageManager::device_load_image(ccl::Device * device, ccl::DeviceScene * dscene, ccl::Scene * scene, ccl::ImageManager::ImageDataType type, int slot, ccl::Progress * progress) Line 761	C++
 	[External Code]	
 	blender.exe!ccl::TaskPool::wait_work(ccl::TaskPool::Summary * stats) Line 98	C++
 	blender.exe!ccl::ImageManager::device_update(ccl::Device * device, ccl::DeviceScene * dscene, ccl::Scene * scene, ccl::Progress & progress) Line 946	C++
 	blender.exe!ccl::Scene::device_update(ccl::Device * device_, ccl::Progress & progress) Line 192	C++
 	blender.exe!ccl::Session::update_scene() Line 818	C++
 	blender.exe!ccl::Session::run_cpu() Line 546	C++
 	blender.exe!ccl::Session::run() Line 690	C++
 	blender.exe!ccl::thread::run(void * arg) Line 57	C++
 	pthreadVC2.dll!000007fee771627b()	Unknown
 	pthreadVC2.dll!000007fee7718eb7()	Unknown
 	pthreadVC2.dll!000007fee7719102()	Unknown
 	[External Code]

it does seem to come from the rBb047d79 change, @Sergey Sharybin (sergey) mind taking a peek?

allocates a buffer 1280(w)*720(h)*1(d) but

copies num_pixels(w*h*d) * components (4) bytes of data neatly overflowing the buffer with 4 times as much data as it can take.

Sergey Sharybin (sergey) changed the task status from Unknown Status to Resolved.Feb 12 2017, 10:43 AM
Sergey Sharybin (sergey) claimed this task.

Crash should be fixed now. Thanks for the report.