Crash rendering image as plane with this particular Tif (Cycles)
Closed, DuplicatePublic


System Information
Kubuntu 14.04 64bits (Linux)
GTX 960 - 378.13

Blender Version
Broken: 2.78x - Master
Short description of error
I'm having a crash (segmentation fault) when I import as plane an specific tif obtained from Darktable, and render image or rendered view. Problem does not happen with any tif, and this does not happen if the tif is packaged in .blend. Here I share the tif packed, so you unpack first to test.

(Clarification: tif Image is black on purpose)

Exact steps for others to reproduce the error
Open the .blend. File > External data > and untick Automatically into .blend
File > External data > Unpack all into files > Use files in current directory
Render image (or rendered view)
Blender crash


Lukas Stockner (lukasstockner97) triaged this task as "Confirmed" priority.Mar 6 2017, 4:11 AM

I can reproduce the crash, it happens inside of OIIO - to be precise, in OpenImageIO::v1_4::TIFFInput::find_tag which is called by intern/cycles/render/image.cpp:164.
Apparently Blender's image loading code can handle the Image, which is why it works when packed and only crashes when it's read from disk by OIIO.

@YAFU (YAFU), Does rendering also crash with the original file or only after packing and unpacking?

In any case, I'm not sure whether Darktable writes invalid TIFFs or OIIO is reading them incorrectly. I'll recheck with latest OIIO, if it still crashes there we should probably report it upstream.

YAFU (YAFU) added a comment.EditedMar 6 2017, 12:50 PM

@Lukas Stockner (lukasstockner97) , This is the story: I was having these crashes when trying to use image as plane with my photos revealed and exported from Darktable (tif format). The crash was always reproducible, I always did the tests without packing the tif in .blend file.
So then I had decided to report the problem, and because the problem does not occur with any tif, I decide to pack the tif into .blend file to include in the report. So before sending the file I do the test again, and, wait a minute!... Is there when I find that packed tif does not produce the crash.
So yes, the problem basically happened with the original file.

@Fable Fox (fablefox) , this is de crash log:

Okay, this is getting weird - I could reproduce the issue with OIIO 1.6.9, but after upgrading my build environment to 1.7.8 the crash is gone.
However, the official 2.78c which is also linked against OIIO 1.7.8 still crashes.

I'll try to isolate the issue, but it seems that it's not as easy as just upgrading OIIO.

This is similar to T50850, same root of the problem here.