[Bf-committers] [Bf-blender-cvs] SVN commit: /data/svn/bf-blender [51027] trunk/blender/source/blender/imbuf /intern/colormanagement.c: colormanage_colorspace_get_named() can (and does ) return NULL, added checks to prevent null pointer dereferen

Sergey Sharybin sergey.vfx at gmail.com
Thu Oct 4 09:05:46 CEST 2012

This isn't usual scenario behavior (you *should* have OCIO configuration).
Correct fix would be to fallback to "stub"-based OCIO API which would be
much more predictable and which isn't so much difficult to implement. I
know about this issue and i'll work on this after codebase unfreeze.

The issue with your fix is missing configuration could backfire in lots of
other places.

On Thu, Oct 4, 2012 at 12:50 PM, Dan Eicher <dan at trollwerks.org> wrote:

> On Wed, Oct 3, 2012 at 11:21 PM, Sergey Sharybin <sergey.vfx at gmail.com>
> wrote:
> > Function you mentioned should not return null and if if does -- some
> > datablock's color space is configured wrong and that's what should be
> fixed.
> >
> > This probably prevents crash but currently i don't consider it's a
> correct
> > fix and would want to have feedback about circumstances when crash
> happens
> > here.
> This prevents a crash if the colorspace data file can't be found --
> blender just complains about the OCIO environmental variable instead
> of segfaulting which IMHO is a little more user friendly. To reproduce
> the crash just move the datafiles/colormanagment folder somewhere
> blender can't find it.
> This doesn't fix any color management issues or anything like that, it
> just checks for a null pointer being returned from a function that
> *can* return NULL...easy peasy.
> Dan
> _______________________________________________
> Bf-committers mailing list
> Bf-committers at blender.org
> http://lists.blender.org/mailman/listinfo/bf-committers

With best regards, Sergey Sharybin

More information about the Bf-committers mailing list