Date   

building latest release w/ Visual Studio 2012

Paul Miller <pa...@...>
 

Trying to build master and the build process is failing trying to process tinyxml and yaml, such as this:

2>------ Build started: Project: tinyxml, Configuration: Debug x64 ------
2> Building Custom Rule D:/paul/src/OpenColorIO/CMakeLists.txt
2> CMake does not need to re-run because D:\paul\src\OpenColorIO\build\CMakeFiles\generate.stamp is up-to-date.
2> Creating directories for 'tinyxml'
2> Performing download step (verify and extract) for 'tinyxml'
2> -- verifying file...
2> file='D:/paul/src/OpenColorIO/ext/tinyxml_2_6_1.tar.gz'
2>CUSTOMBUILD : -- verifying file... warning : did not verify file - no URL_HASH specified?
2> -- extracting...
2> src='D:/paul/src/OpenColorIO/ext/tinyxml_2_6_1.tar.gz'
2> dst='D:/paul/src/OpenColorIO/build/tinyxml-prefix/src/tinyxml'
2> -- extracting... [tar xfz]
2> -- extracting... [analysis]
2> -- extracting... [rename]
2> -- extracting... [clean up]
2> -- extracting... done
2> No update step for 'tinyxml'
2> Performing patch step for 'tinyxml'
2> 'patch' is not recognized as an internal or external command,
2> operable program or batch file.
2>C:\Program Files (x86)\MSBuild\Microsoft.Cpp\v4.0\V110\Microsoft.CppCommon.targets(172,5): error MSB6006: "cmd.exe" exited with code 9009.
========== Build: 1 succeeded, 1 failed, 0 up-to-date, 0 skipped ==========

This later prevents the OpenColorIO target from building.
I also tried with the frederikaalund:master pull request with the same results.

Any suggestions?


Re: OS X 10.9 build/link issues w/ XCode 5.1.1

Mark Boorer <mark...@...>
 

Hi Paul,

Could you perhaps copy in the link errors here?

Also are you building OCIO with the same C++11 features enabled?

Cheers,
Mark

On Fri, Sep 5, 2014 at 4:14 PM, Paul Miller <pa...@...> wrote:
I'm trying to use OCIO with an application built with XCode 5.1.1.

I can configure and build OCIO fine, but when I try to link it into my
application there are link errors.

I'm not using boost pointers, but standard C++11 pointers, in both places.

Anyone else have a similar issue?

--
You received this message because you are subscribed to the Google Groups
"OpenColorIO Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an
email to ocio-dev+u...@....
For more options, visit https://groups.google.com/d/optout.


OS X 10.9 build/link issues w/ XCode 5.1.1

Paul Miller <pa...@...>
 

I'm trying to use OCIO with an application built with XCode 5.1.1.

I can configure and build OCIO fine, but when I try to link it into my application there are link errors.

I'm not using boost pointers, but standard C++11 pointers, in both places.

Anyone else have a similar issue?


How to use OCIO::ROLE_COLOR_PICKER

Antony Riakiotakis <kal...@...>
 

Hi,

I'm trying to hook up OCIO properly to blender's color picker system and allow choosing an arbitrary color tranform before uploading the color picker colors to our display device.
 
In blender, by default, we have a standard linear reference color space with srgb primaries, and our display transform is non-linear srgb.

The issue I am having is that I suspect that defining a color picker color space and then defining a processor from that space to display space will not help at all since it will void the transform to the color picker color space. I could probably write additional color spaces that "act" on display color space but I imagine that if I did that then OCIO would first convert my colors to the display space and then perform the transforms (I may misunderstand something here, please correct me if I'm wrong).
Is there a way to keep the color picker space transform and upload properly to the device by applying the device dependent transform without transforming to the device color space?

I have digged a few emails and found that OCIO::ROLE_COLOR_PICKER may do what I want, but found no comprehensive examples. Can someone point me to an example and/or explain how to use something like this?

Thanks!


Re: PyOpenColorIO on Windows - how?

Simon Björk <si...@...>
 

Hi Mark,

thanks for your reply. I'm using Python 2.7.8, downloaded from python.org.

Thanks for taking a look at it!

Best regards,
Simon



-------------------------------
Simon Björk
Compositor/TD

+46 (0)70-2859503


2014-08-22 17:55 GMT+02:00 Mark Boorer <mark...@...>:

Hi Simon,

Unfortunately I haven't really had much of a look into the windows building process. Just wanted to clarify a few things though. Which version of python are you using (and was it one distributed by python.org or one you built yourself?).

If you built it yourself, which compiler / msvc version were you using?

Can't promise a speedy resolution to your problem, but I'll give it a stab when I get the chance.

Cheers,
Mark


On Tue, Aug 19, 2014 at 10:45 PM, Simon Björk <si...@...> wrote:
I'm trying to install PyOpenColorIO on my Windows machine, but I'm not having any success. Does anyone have this working?

I've tried with both Marie's build and the one that comes with the precompiled Windows version of OpenImageIO found here.

When I try to import PyOpenColorIO I get the following message: mportError: DLL load failed: %1 is not a valid Win32 application.

Thanks for you help.

Best regards,
Simon







-------------------------------
Simon Björk
Compositor/TD

--
You received this message because you are subscribed to the Google Groups "OpenColorIO Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ocio-dev+u...@....
For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups "OpenColorIO Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ocio-dev+u...@....
For more options, visit https://groups.google.com/d/optout.


Re: PyOpenColorIO on Windows - how?

Mark Boorer <mark...@...>
 

Hi Simon,

Unfortunately I haven't really had much of a look into the windows building process. Just wanted to clarify a few things though. Which version of python are you using (and was it one distributed by python.org or one you built yourself?).

If you built it yourself, which compiler / msvc version were you using?

Can't promise a speedy resolution to your problem, but I'll give it a stab when I get the chance.

Cheers,
Mark


On Tue, Aug 19, 2014 at 10:45 PM, Simon Björk <si...@...> wrote:
I'm trying to install PyOpenColorIO on my Windows machine, but I'm not having any success. Does anyone have this working?

I've tried with both Marie's build and the one that comes with the precompiled Windows version of OpenImageIO found here.

When I try to import PyOpenColorIO I get the following message: mportError: DLL load failed: %1 is not a valid Win32 application.

Thanks for you help.

Best regards,
Simon







-------------------------------
Simon Björk
Compositor/TD

--
You received this message because you are subscribed to the Google Groups "OpenColorIO Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ocio-dev+u...@....
For more options, visit https://groups.google.com/d/optout.


PyOpenColorIO on Windows - how?

Simon Björk <si...@...>
 

I'm trying to install PyOpenColorIO on my Windows machine, but I'm not having any success. Does anyone have this working?

I've tried with both Marie's build and the one that comes with the precompiled Windows version of OpenImageIO found here.

When I try to import PyOpenColorIO I get the following message: mportError: DLL load failed: %1 is not a valid Win32 application.

Thanks for you help.

Best regards,
Simon







-------------------------------
Simon Björk
Compositor/TD

+46 (0)70-2859503


Re: Review: Inital pass at searchpath impl

Kevin Wheatley <kevin.j....@...>
 

When I looked at trying to use per-shot grades last, I ended up with the limitation that you couldn't dynamically determine the representation which meant you could not have say a 3D LUT for one shot and a CDL for another.

Something that I did manage to make work was a layering approach allowing a top level look to be published, followed by more specific sequence and under that shot grades, although that didn't scale well it involved well structuring paths and names of files and using the search path capability to find the right one - needless to say this was a very twisted approach to achieving this - it didn't handle multiple versions of looks/grades, which combined with the fact that vendor supplied applications don't necessarily fully expose the OCIO capabilities meant I gave up and did something  less twisted.

As for per shot variables with edited timelines, I was utilizing the config overrides to replace environment variable settings, this worked great in Nuke and other similar applications where this is exposed, but lots of tools don't expose the feature for instance heiro/heiroplayer would be a suitable place to do this.

Kevin



Re: Review: Inital pass at searchpath impl

Tobias Pfeiffer <pixeld...@...>
 

Hi guys,
I do understand the limitations of the use of env vars to point to shot grades, but dont know how to deal with it (even 4 years later) in case of flipbooking with RV.
Do you have any suggestions / Best Practices for that?
Thank you.
Tobi

Am Freitag, 29. Oktober 2010 00:24:03 UTC+2 schrieb Jeremy Selan:

There's a lot of good ideas here, it's taken me a bit of time to think
through the implications.

I'm going to be out of town for the remainder of the week, perhaps we
could try an internet call early next week to discuss these specifics
further?  (Skype, iChat, etc).  Many of these points can probably be
hashed out easier live, and then we can summarize our thoughts back to
the list.

> What about per shot balance grades and look / creative grades, I would cry if I needed to create a zip ocio profile per shot to do this. > Then re-syncing these profiles would be a nightmare.

Agreed.  Under no circumstances are we going to make per-shot looks
complicated to use. We're in the same boat here.

>> JS:  I think it will be preferable when possible to minimize the use of envvars.
> MH: Can you elaborate on this?

Your approach to implementing per-shot looks - using environment
variables within search paths - is clever.  However, I'm not sold.
The portion I'm concerned about is the use of environment variables as
a communications mechanism.

For an application (such as a compositor) where you're not changing
show / shot / sequence at runtime the use of envvars is no big deal.
For example, say you have a per-shot display lut
(/job/$SHOT/.../shotgrade.3dl).   You could run a script which sets up
the shot environment, launch the APP, and everything just works.

However, consider an image-viewing tool which needs to flipbook
multiple shots (or whole sequences) back to back. I.e., the display
transform, as queried from OCIO, would be different based on the shot
name. Would this approach be possible using an envvar mechanism?  I
dont believe so.   Envvars are commonly locked down at launch time.
And, even if you could modify it at runtime as playback was in
progress, would you want to? How would you notifiy OCIO that it had
changed?  This seems like a tricky implementation, and strikes me as
going down the path of evil.

I would prefer to promote this concept of 'variables' to be an
explicit communications mechanism, rather then using envvars as a
back-door.  Alternate implementation options include:

* a config->setVariable option,  where variables were available for
use in color transforms.  (They could even retain the $SHOW $SHOT
syntax).  This way the OCIO plugin could set it as needed, and with
the python API exposed in client apps the list of variables could even
be amended with facility code, as needed at runtime!

* Alternatively,  with a less stateful implementation the variables /
arguments could be passed along in the config->getProcessor call. This
may be preferable to those computer scientists among us.

Either way, this passing of variables as arguments to a transforms is
half of the work towards allowing fully dynamic colorspaces. (The
other 1/2 being the plugin API to define the lists of transforms at
runtime).

Perhaps this is good reason to move forward on both ASAP?

-- Jeremy


Re: Windows Build

Tobias Pfeiffer <pixeld...@...>
 

thanks a lot for this!

Am Montag, 21. Oktober 2013 17:15:40 UTC+2 schrieb Marie Fétiveau:

Hello !

OpenColorIO.dll and ociobakelut.exe :
Built with msvc10 on win7 (64 bits).

No time right now to do a full build but I'll try next time I'm on Windows.

++

Marie


On Thu, Oct 17, 2013 at 1:54 AM, Jeremy Selan <jere...@...> wrote:
Does anyone have an OCIO build already made for Windows that they're
willing to share?

Specifically, we're interested most in the OpenColorIO.dll and
ociobakelut.exe, but it would be great to get ALL the command-line
utilities if available.

Thanks!

-- Jeremy

--
You received this message because you are subscribed to the Google Groups "OpenColorIO Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ocio-dev+u...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.


Re: Crash issue having multiple active_displays in a config

simon smith <si.c....@...>
 

Hi Mark - just to confirm that the fix works (as expected) just fine.


On Friday, July 25, 2014 1:17:18 PM UTC+1, simon smith wrote:
I can't check that immediately, but when I have got the time to check it out I shall report back.

Thanks for the help Mark.


  - Simon.

On Friday, July 25, 2014 12:33:23 AM UTC+1, Mark Boorer wrote:
Hi, Just following up.

This issue should now be resolved. I have patched OCIOYaml.cpp, and pushed those changes to master. If you are able, could you confirm that this solves your issue?

Cheers,
Mark


On Thu, Jul 24, 2014 at 11:47 AM, Mark Boorer <mar...@...> wrote:
Ah right, now I see where the problem is!

Thanks for the breakdown, I've opened an issue on the github bug tracker, and I'll look to patching this tonight.

https://github.com/imageworks/OpenColorIO/issues/365

There are a couple of other places where this happens too

Thanks again!

Cheers,
Mark




On Thu, Jul 24, 2014 at 8:51 AM, simon smith <si.c...@...> wrote:
Hi Mark,

I'm using Visual Studio 2012, 64-bit compilation in debug.
If you view the disassembly of OCIOYaml.cpp in the load function  (or set a breakpoint in ~basic_string) you can see where it's destroyed as follows:

                {

                    std::vector<std::string> display;
00007FFDA504E132  lea         rcx,[rsp+0C28h] 
00007FFDA504E13A  call        std::vector<std::basic_string<char,std::char_traits<char>,std::allocator<char> >,std::allocator<std::basic_string<char,std::char_traits<char>,std::allocator<char> > > >::vector<std::basic_string<char,std::char_traits<char>,std::allocator<char> >,std::allocator<std::basic_string<char,std::char_traits<char>,std::allocator<char> > > > (07FFDA4F35CAEh) 
00007FFDA504E13F  nop 
                    load(second, display);
00007FFDA504E140  lea         rdx,[rsp+0C28h] 
00007FFDA504E148  mov         rcx,qword ptr [rsp+3B0h] 
00007FFDA504E150  call        OpenColorIO::v1::`anonymous namespace'::load (07FFDA4F357D6h) 
                    const char* displays = JoinStringEnvStyle(display).c_str();
00007FFDA504E155  lea         rdx,[rsp+0C28h] 
00007FFDA504E15D  lea         rcx,[rsp+0C60h] 
00007FFDA504E165  call        OpenColorIO::v1::JoinStringEnvStyle (07FFDA4F331BBh) 
00007FFDA504E16A  mov         qword ptr [rsp+1898h],rax 
00007FFDA504E172  mov         rcx,qword ptr [rsp+1898h] 
00007FFDA504E17A  call        std::basic_string<char,std::char_traits<char>,std::allocator<char> >::c_str (07FFDA4F35EB6h) 
00007FFDA504E17F  mov         qword ptr [rsp+0C58h],rax 
00007FFDA504E187  lea         rcx,[rsp+0C60h] 
00007FFDA504E18F  call        std::basic_string<char,std::char_traits<char>,std::allocator<char> >::~basic_string<char,std::char_traits<char>,std::allocator<char> > (07FFDA4F36F82h) 
                    c->setActiveDisplays(displays);
00007FFDA504E194  mov         rcx,qword ptr [c] 
00007FFDA504E19C  call        boost::shared_ptr<OpenColorIO::v1::Config>::operator-> (07FFDA4F33972h) 
00007FFDA504E1A1  mov         rdx,qword ptr [rsp+0C58h] 
00007FFDA504E1A9  mov         rcx,rax 
00007FFDA504E1AC  call        OpenColorIO::v1::Config::setActiveDisplays (07FFDA4F33323h) 


Hopefully this displays OK for you.
You can see just before the c->setActiveDisplays(displays) the string destructor fires.
So the pointer passed to setActiveDisplay is thus now pointing to freed memory ....

This kind of makes sense - the scope is just for the return value as the object is not assigned to anything (the *contents* are, the c_str, but std::string doesn't reference count that!) but I suspect some compilers aren't so eager to destroy the returned string as Visual Studio 2012 ....


Simon.




On Wednesday, July 23, 2014 12:55:30 AM UTC+1, Mark Boorer wrote:
Hi Simon,

Not sure I see where a bug could be hiding. The scoping around those blocks seems fine to me.
setActiveDisplays(), though taking a const char * as an argument, never actually stores it internally, instead opting to store the results of another call to SplitStringEnvStyle().

SplitStringEnvStyle() makes a new std::string via pystring::strip as one of its first operations, so there is no possibility of char pointers falling out of scope.

This has been fairly stable code (since around 2011), though admittedly OCIOYaml.cpp has recently undergone some changes.

Would you happen to have some more information as to your development environment? Visual Studio / OCIO versions / ways to reproduce the crash you're seeing?

With a little more information I'll hopefully be able to root out the cause of the issue.

Cheers,
Mark


On Tue, Jul 22, 2014 at 4:03 PM, simon smith <si.c...@...> wrote:
I'm testing out some code and I've noticed a crash issue when a config (such as ACES, from the ICIO website) contain multiple active displays or views.

Basically, the code in ICIOYaml.cpp that takes an array of displays tries to join them together into one string using the JoinStringEnvStyle function (in ParseUtils.cpp) is flawed.

JoinStringEnvStyle will return a new std::string instance if more than one string is found in the array (it will pass the original "array" string back if there is only one entry in it).

The caller of JoinStringEnvStylein OCIOYaml.cpp takes a const pointer to this returned std::string to pass to the next function (setActiveDisplays) but it falls out of scope as soon as the const char* has been taken (it goes out of scope as it enters the next line of code). Thus on the next line the pointer is pointing to freed memory. You probably get away with this in release, but in debug (under windows) it will write freed memory markers as guards for this type of thing.

The code currently is:

std::vector<std::string> display;
load(second, display);
const char* displays = JoinStringEnvStyle(display).c_str();
c->setActiveDisplays(displays);

You can easily see the scope issue here.
I suspect a fix would be along the lines of:

std::vector<std::string> display;
load(second, display);
std::string strDisplays = JoinStringEnvStyle(display).c_str();
const char* displays = strDisplays.c_str();
c->setActiveDisplays(displays);

I thought I'd pass this on as I've not seen any notes on it anywhere, but it must be an issue for everyone.


 - Simon.

--
You received this message because you are subscribed to the Google Groups "OpenColorIO Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ocio-dev+u...@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups "OpenColorIO Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ocio-d...@....
For more options, visit https://groups.google.com/d/optout.



Re: OCIO error in Hiero

Deke Kincaid <dekek...@...>
 

Hi Jose

You are using a 3d lut which is not reversible.  Only 1d luts are reversible.  Is this a lut that you created?


On Fri, Jul 25, 2014 at 3:47 PM, Jose Enriquez <jenr...@...> wrote:
Hello everyone, I have a problem creating a lut from nuke to hiero, in hiero I receive this error;

LogCrec709 inverse; 1 OpenColor IO Error: 3D Lusts can only e applied in the foward direction.inverse specified

And can't see correctly the Alexa Proress in hiero,

Does anyone had this problem or a solution?

:D

--
You received this message because you are subscribed to the Google Groups "OpenColorIO Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ocio-dev+u...@....
For more options, visit https://groups.google.com/d/optout.


OCIO error in Hiero

Jose Enriquez <jenr...@...>
 

Hello everyone, I have a problem creating a lut from nuke to hiero, in hiero I receive this error;

LogCrec709 inverse; 1 OpenColor IO Error: 3D Lusts can only e applied in the foward direction.inverse specified

And can't see correctly the Alexa Proress in hiero,

Does anyone had this problem or a solution?

:D


Re: Crash issue having multiple active_displays in a config

simon smith <si.c....@...>
 

I can't check that immediately, but when I have got the time to check it out I shall report back.

Thanks for the help Mark.


  - Simon.


On Friday, July 25, 2014 12:33:23 AM UTC+1, Mark Boorer wrote:
Hi, Just following up.

This issue should now be resolved. I have patched OCIOYaml.cpp, and pushed those changes to master. If you are able, could you confirm that this solves your issue?

Cheers,
Mark


On Thu, Jul 24, 2014 at 11:47 AM, Mark Boorer <mar...@...> wrote:
Ah right, now I see where the problem is!

Thanks for the breakdown, I've opened an issue on the github bug tracker, and I'll look to patching this tonight.

https://github.com/imageworks/OpenColorIO/issues/365

There are a couple of other places where this happens too

Thanks again!

Cheers,
Mark




On Thu, Jul 24, 2014 at 8:51 AM, simon smith <si.c...@...> wrote:
Hi Mark,

I'm using Visual Studio 2012, 64-bit compilation in debug.
If you view the disassembly of OCIOYaml.cpp in the load function  (or set a breakpoint in ~basic_string) you can see where it's destroyed as follows:

                {

                    std::vector<std::string> display;
00007FFDA504E132  lea         rcx,[rsp+0C28h] 
00007FFDA504E13A  call        std::vector<std::basic_string<char,std::char_traits<char>,std::allocator<char> >,std::allocator<std::basic_string<char,std::char_traits<char>,std::allocator<char> > > >::vector<std::basic_string<char,std::char_traits<char>,std::allocator<char> >,std::allocator<std::basic_string<char,std::char_traits<char>,std::allocator<char> > > > (07FFDA4F35CAEh) 
00007FFDA504E13F  nop 
                    load(second, display);
00007FFDA504E140  lea         rdx,[rsp+0C28h] 
00007FFDA504E148  mov         rcx,qword ptr [rsp+3B0h] 
00007FFDA504E150  call        OpenColorIO::v1::`anonymous namespace'::load (07FFDA4F357D6h) 
                    const char* displays = JoinStringEnvStyle(display).c_str();
00007FFDA504E155  lea         rdx,[rsp+0C28h] 
00007FFDA504E15D  lea         rcx,[rsp+0C60h] 
00007FFDA504E165  call        OpenColorIO::v1::JoinStringEnvStyle (07FFDA4F331BBh) 
00007FFDA504E16A  mov         qword ptr [rsp+1898h],rax 
00007FFDA504E172  mov         rcx,qword ptr [rsp+1898h] 
00007FFDA504E17A  call        std::basic_string<char,std::char_traits<char>,std::allocator<char> >::c_str (07FFDA4F35EB6h) 
00007FFDA504E17F  mov         qword ptr [rsp+0C58h],rax 
00007FFDA504E187  lea         rcx,[rsp+0C60h] 
00007FFDA504E18F  call        std::basic_string<char,std::char_traits<char>,std::allocator<char> >::~basic_string<char,std::char_traits<char>,std::allocator<char> > (07FFDA4F36F82h) 
                    c->setActiveDisplays(displays);
00007FFDA504E194  mov         rcx,qword ptr [c] 
00007FFDA504E19C  call        boost::shared_ptr<OpenColorIO::v1::Config>::operator-> (07FFDA4F33972h) 
00007FFDA504E1A1  mov         rdx,qword ptr [rsp+0C58h] 
00007FFDA504E1A9  mov         rcx,rax 
00007FFDA504E1AC  call        OpenColorIO::v1::Config::setActiveDisplays (07FFDA4F33323h) 


Hopefully this displays OK for you.
You can see just before the c->setActiveDisplays(displays) the string destructor fires.
So the pointer passed to setActiveDisplay is thus now pointing to freed memory ....

This kind of makes sense - the scope is just for the return value as the object is not assigned to anything (the *contents* are, the c_str, but std::string doesn't reference count that!) but I suspect some compilers aren't so eager to destroy the returned string as Visual Studio 2012 ....


Simon.




On Wednesday, July 23, 2014 12:55:30 AM UTC+1, Mark Boorer wrote:
Hi Simon,

Not sure I see where a bug could be hiding. The scoping around those blocks seems fine to me.
setActiveDisplays(), though taking a const char * as an argument, never actually stores it internally, instead opting to store the results of another call to SplitStringEnvStyle().

SplitStringEnvStyle() makes a new std::string via pystring::strip as one of its first operations, so there is no possibility of char pointers falling out of scope.

This has been fairly stable code (since around 2011), though admittedly OCIOYaml.cpp has recently undergone some changes.

Would you happen to have some more information as to your development environment? Visual Studio / OCIO versions / ways to reproduce the crash you're seeing?

With a little more information I'll hopefully be able to root out the cause of the issue.

Cheers,
Mark


On Tue, Jul 22, 2014 at 4:03 PM, simon smith <si.c...@...> wrote:
I'm testing out some code and I've noticed a crash issue when a config (such as ACES, from the ICIO website) contain multiple active displays or views.

Basically, the code in ICIOYaml.cpp that takes an array of displays tries to join them together into one string using the JoinStringEnvStyle function (in ParseUtils.cpp) is flawed.

JoinStringEnvStyle will return a new std::string instance if more than one string is found in the array (it will pass the original "array" string back if there is only one entry in it).

The caller of JoinStringEnvStylein OCIOYaml.cpp takes a const pointer to this returned std::string to pass to the next function (setActiveDisplays) but it falls out of scope as soon as the const char* has been taken (it goes out of scope as it enters the next line of code). Thus on the next line the pointer is pointing to freed memory. You probably get away with this in release, but in debug (under windows) it will write freed memory markers as guards for this type of thing.

The code currently is:

std::vector<std::string> display;
load(second, display);
const char* displays = JoinStringEnvStyle(display).c_str();
c->setActiveDisplays(displays);

You can easily see the scope issue here.
I suspect a fix would be along the lines of:

std::vector<std::string> display;
load(second, display);
std::string strDisplays = JoinStringEnvStyle(display).c_str();
const char* displays = strDisplays.c_str();
c->setActiveDisplays(displays);

I thought I'd pass this on as I've not seen any notes on it anywhere, but it must be an issue for everyone.


 - Simon.

--
You received this message because you are subscribed to the Google Groups "OpenColorIO Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ocio-dev+u...@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups "OpenColorIO Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ocio-dev+u...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.



Re: Crash issue having multiple active_displays in a config

Mark Boorer <mark...@...>
 

Hi, Just following up.

This issue should now be resolved. I have patched OCIOYaml.cpp, and pushed those changes to master. If you are able, could you confirm that this solves your issue?

Cheers,
Mark


On Thu, Jul 24, 2014 at 11:47 AM, Mark Boorer <mark...@...> wrote:
Ah right, now I see where the problem is!

Thanks for the breakdown, I've opened an issue on the github bug tracker, and I'll look to patching this tonight.

https://github.com/imageworks/OpenColorIO/issues/365

There are a couple of other places where this happens too

Thanks again!

Cheers,
Mark




On Thu, Jul 24, 2014 at 8:51 AM, simon smith <si.c....@...> wrote:
Hi Mark,

I'm using Visual Studio 2012, 64-bit compilation in debug.
If you view the disassembly of OCIOYaml.cpp in the load function  (or set a breakpoint in ~basic_string) you can see where it's destroyed as follows:

                {

                    std::vector<std::string> display;
00007FFDA504E132  lea         rcx,[rsp+0C28h] 
00007FFDA504E13A  call        std::vector<std::basic_string<char,std::char_traits<char>,std::allocator<char> >,std::allocator<std::basic_string<char,std::char_traits<char>,std::allocator<char> > > >::vector<std::basic_string<char,std::char_traits<char>,std::allocator<char> >,std::allocator<std::basic_string<char,std::char_traits<char>,std::allocator<char> > > > (07FFDA4F35CAEh) 
00007FFDA504E13F  nop 
                    load(second, display);
00007FFDA504E140  lea         rdx,[rsp+0C28h] 
00007FFDA504E148  mov         rcx,qword ptr [rsp+3B0h] 
00007FFDA504E150  call        OpenColorIO::v1::`anonymous namespace'::load (07FFDA4F357D6h) 
                    const char* displays = JoinStringEnvStyle(display).c_str();
00007FFDA504E155  lea         rdx,[rsp+0C28h] 
00007FFDA504E15D  lea         rcx,[rsp+0C60h] 
00007FFDA504E165  call        OpenColorIO::v1::JoinStringEnvStyle (07FFDA4F331BBh) 
00007FFDA504E16A  mov         qword ptr [rsp+1898h],rax 
00007FFDA504E172  mov         rcx,qword ptr [rsp+1898h] 
00007FFDA504E17A  call        std::basic_string<char,std::char_traits<char>,std::allocator<char> >::c_str (07FFDA4F35EB6h) 
00007FFDA504E17F  mov         qword ptr [rsp+0C58h],rax 
00007FFDA504E187  lea         rcx,[rsp+0C60h] 
00007FFDA504E18F  call        std::basic_string<char,std::char_traits<char>,std::allocator<char> >::~basic_string<char,std::char_traits<char>,std::allocator<char> > (07FFDA4F36F82h) 
                    c->setActiveDisplays(displays);
00007FFDA504E194  mov         rcx,qword ptr [c] 
00007FFDA504E19C  call        boost::shared_ptr<OpenColorIO::v1::Config>::operator-> (07FFDA4F33972h) 
00007FFDA504E1A1  mov         rdx,qword ptr [rsp+0C58h] 
00007FFDA504E1A9  mov         rcx,rax 
00007FFDA504E1AC  call        OpenColorIO::v1::Config::setActiveDisplays (07FFDA4F33323h) 


Hopefully this displays OK for you.
You can see just before the c->setActiveDisplays(displays) the string destructor fires.
So the pointer passed to setActiveDisplay is thus now pointing to freed memory ....

This kind of makes sense - the scope is just for the return value as the object is not assigned to anything (the *contents* are, the c_str, but std::string doesn't reference count that!) but I suspect some compilers aren't so eager to destroy the returned string as Visual Studio 2012 ....


Simon.




On Wednesday, July 23, 2014 12:55:30 AM UTC+1, Mark Boorer wrote:
Hi Simon,

Not sure I see where a bug could be hiding. The scoping around those blocks seems fine to me.
setActiveDisplays(), though taking a const char * as an argument, never actually stores it internally, instead opting to store the results of another call to SplitStringEnvStyle().

SplitStringEnvStyle() makes a new std::string via pystring::strip as one of its first operations, so there is no possibility of char pointers falling out of scope.

This has been fairly stable code (since around 2011), though admittedly OCIOYaml.cpp has recently undergone some changes.

Would you happen to have some more information as to your development environment? Visual Studio / OCIO versions / ways to reproduce the crash you're seeing?

With a little more information I'll hopefully be able to root out the cause of the issue.

Cheers,
Mark


On Tue, Jul 22, 2014 at 4:03 PM, simon smith <si.c...@...> wrote:
I'm testing out some code and I've noticed a crash issue when a config (such as ACES, from the ICIO website) contain multiple active displays or views.

Basically, the code in ICIOYaml.cpp that takes an array of displays tries to join them together into one string using the JoinStringEnvStyle function (in ParseUtils.cpp) is flawed.

JoinStringEnvStyle will return a new std::string instance if more than one string is found in the array (it will pass the original "array" string back if there is only one entry in it).

The caller of JoinStringEnvStylein OCIOYaml.cpp takes a const pointer to this returned std::string to pass to the next function (setActiveDisplays) but it falls out of scope as soon as the const char* has been taken (it goes out of scope as it enters the next line of code). Thus on the next line the pointer is pointing to freed memory. You probably get away with this in release, but in debug (under windows) it will write freed memory markers as guards for this type of thing.

The code currently is:

std::vector<std::string> display;
load(second, display);
const char* displays = JoinStringEnvStyle(display).c_str();
c->setActiveDisplays(displays);

You can easily see the scope issue here.
I suspect a fix would be along the lines of:

std::vector<std::string> display;
load(second, display);
std::string strDisplays = JoinStringEnvStyle(display).c_str();
const char* displays = strDisplays.c_str();
c->setActiveDisplays(displays);

I thought I'd pass this on as I've not seen any notes on it anywhere, but it must be an issue for everyone.


 - Simon.

--
You received this message because you are subscribed to the Google Groups "OpenColorIO Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ocio-dev+u...@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups "OpenColorIO Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ocio-dev+u...@....
For more options, visit https://groups.google.com/d/optout.



Re: Crash issue having multiple active_displays in a config

Mark Boorer <mark...@...>
 

Ah right, now I see where the problem is!

Thanks for the breakdown, I've opened an issue on the github bug tracker, and I'll look to patching this tonight.

https://github.com/imageworks/OpenColorIO/issues/365

There are a couple of other places where this happens too

Thanks again!

Cheers,
Mark




On Thu, Jul 24, 2014 at 8:51 AM, simon smith <si.c....@...> wrote:
Hi Mark,

I'm using Visual Studio 2012, 64-bit compilation in debug.
If you view the disassembly of OCIOYaml.cpp in the load function  (or set a breakpoint in ~basic_string) you can see where it's destroyed as follows:

                {

                    std::vector<std::string> display;
00007FFDA504E132  lea         rcx,[rsp+0C28h] 
00007FFDA504E13A  call        std::vector<std::basic_string<char,std::char_traits<char>,std::allocator<char> >,std::allocator<std::basic_string<char,std::char_traits<char>,std::allocator<char> > > >::vector<std::basic_string<char,std::char_traits<char>,std::allocator<char> >,std::allocator<std::basic_string<char,std::char_traits<char>,std::allocator<char> > > > (07FFDA4F35CAEh) 
00007FFDA504E13F  nop 
                    load(second, display);
00007FFDA504E140  lea         rdx,[rsp+0C28h] 
00007FFDA504E148  mov         rcx,qword ptr [rsp+3B0h] 
00007FFDA504E150  call        OpenColorIO::v1::`anonymous namespace'::load (07FFDA4F357D6h) 
                    const char* displays = JoinStringEnvStyle(display).c_str();
00007FFDA504E155  lea         rdx,[rsp+0C28h] 
00007FFDA504E15D  lea         rcx,[rsp+0C60h] 
00007FFDA504E165  call        OpenColorIO::v1::JoinStringEnvStyle (07FFDA4F331BBh) 
00007FFDA504E16A  mov         qword ptr [rsp+1898h],rax 
00007FFDA504E172  mov         rcx,qword ptr [rsp+1898h] 
00007FFDA504E17A  call        std::basic_string<char,std::char_traits<char>,std::allocator<char> >::c_str (07FFDA4F35EB6h) 
00007FFDA504E17F  mov         qword ptr [rsp+0C58h],rax 
00007FFDA504E187  lea         rcx,[rsp+0C60h] 
00007FFDA504E18F  call        std::basic_string<char,std::char_traits<char>,std::allocator<char> >::~basic_string<char,std::char_traits<char>,std::allocator<char> > (07FFDA4F36F82h) 
                    c->setActiveDisplays(displays);
00007FFDA504E194  mov         rcx,qword ptr [c] 
00007FFDA504E19C  call        boost::shared_ptr<OpenColorIO::v1::Config>::operator-> (07FFDA4F33972h) 
00007FFDA504E1A1  mov         rdx,qword ptr [rsp+0C58h] 
00007FFDA504E1A9  mov         rcx,rax 
00007FFDA504E1AC  call        OpenColorIO::v1::Config::setActiveDisplays (07FFDA4F33323h) 


Hopefully this displays OK for you.
You can see just before the c->setActiveDisplays(displays) the string destructor fires.
So the pointer passed to setActiveDisplay is thus now pointing to freed memory ....

This kind of makes sense - the scope is just for the return value as the object is not assigned to anything (the *contents* are, the c_str, but std::string doesn't reference count that!) but I suspect some compilers aren't so eager to destroy the returned string as Visual Studio 2012 ....


Simon.




On Wednesday, July 23, 2014 12:55:30 AM UTC+1, Mark Boorer wrote:
Hi Simon,

Not sure I see where a bug could be hiding. The scoping around those blocks seems fine to me.
setActiveDisplays(), though taking a const char * as an argument, never actually stores it internally, instead opting to store the results of another call to SplitStringEnvStyle().

SplitStringEnvStyle() makes a new std::string via pystring::strip as one of its first operations, so there is no possibility of char pointers falling out of scope.

This has been fairly stable code (since around 2011), though admittedly OCIOYaml.cpp has recently undergone some changes.

Would you happen to have some more information as to your development environment? Visual Studio / OCIO versions / ways to reproduce the crash you're seeing?

With a little more information I'll hopefully be able to root out the cause of the issue.

Cheers,
Mark


On Tue, Jul 22, 2014 at 4:03 PM, simon smith <si.c...@...> wrote:
I'm testing out some code and I've noticed a crash issue when a config (such as ACES, from the ICIO website) contain multiple active displays or views.

Basically, the code in ICIOYaml.cpp that takes an array of displays tries to join them together into one string using the JoinStringEnvStyle function (in ParseUtils.cpp) is flawed.

JoinStringEnvStyle will return a new std::string instance if more than one string is found in the array (it will pass the original "array" string back if there is only one entry in it).

The caller of JoinStringEnvStylein OCIOYaml.cpp takes a const pointer to this returned std::string to pass to the next function (setActiveDisplays) but it falls out of scope as soon as the const char* has been taken (it goes out of scope as it enters the next line of code). Thus on the next line the pointer is pointing to freed memory. You probably get away with this in release, but in debug (under windows) it will write freed memory markers as guards for this type of thing.

The code currently is:

std::vector<std::string> display;
load(second, display);
const char* displays = JoinStringEnvStyle(display).c_str();
c->setActiveDisplays(displays);

You can easily see the scope issue here.
I suspect a fix would be along the lines of:

std::vector<std::string> display;
load(second, display);
std::string strDisplays = JoinStringEnvStyle(display).c_str();
const char* displays = strDisplays.c_str();
c->setActiveDisplays(displays);

I thought I'd pass this on as I've not seen any notes on it anywhere, but it must be an issue for everyone.


 - Simon.

--
You received this message because you are subscribed to the Google Groups "OpenColorIO Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ocio-dev+u...@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups "OpenColorIO Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ocio-dev+u...@....
For more options, visit https://groups.google.com/d/optout.


Re: Crash issue having multiple active_displays in a config

simon smith <si.c....@...>
 

Hi Mark,

I'm using Visual Studio 2012, 64-bit compilation in debug.
If you view the disassembly of OCIOYaml.cpp in the load function  (or set a breakpoint in ~basic_string) you can see where it's destroyed as follows:

                {
                    std::vector<std::string> display;
00007FFDA504E132  lea         rcx,[rsp+0C28h] 
00007FFDA504E13A  call        std::vector<std::basic_string<char,std::char_traits<char>,std::allocator<char> >,std::allocator<std::basic_string<char,std::char_traits<char>,std::allocator<char> > > >::vector<std::basic_string<char,std::char_traits<char>,std::allocator<char> >,std::allocator<std::basic_string<char,std::char_traits<char>,std::allocator<char> > > > (07FFDA4F35CAEh) 
00007FFDA504E13F  nop 
                    load(second, display);
00007FFDA504E140  lea         rdx,[rsp+0C28h] 
00007FFDA504E148  mov         rcx,qword ptr [rsp+3B0h] 
00007FFDA504E150  call        OpenColorIO::v1::`anonymous namespace'::load (07FFDA4F357D6h) 
                    const char* displays = JoinStringEnvStyle(display).c_str();
00007FFDA504E155  lea         rdx,[rsp+0C28h] 
00007FFDA504E15D  lea         rcx,[rsp+0C60h] 
00007FFDA504E165  call        OpenColorIO::v1::JoinStringEnvStyle (07FFDA4F331BBh) 
00007FFDA504E16A  mov         qword ptr [rsp+1898h],rax 
00007FFDA504E172  mov         rcx,qword ptr [rsp+1898h] 
00007FFDA504E17A  call        std::basic_string<char,std::char_traits<char>,std::allocator<char> >::c_str (07FFDA4F35EB6h) 
00007FFDA504E17F  mov         qword ptr [rsp+0C58h],rax 
00007FFDA504E187  lea         rcx,[rsp+0C60h] 
00007FFDA504E18F  call        std::basic_string<char,std::char_traits<char>,std::allocator<char> >::~basic_string<char,std::char_traits<char>,std::allocator<char> > (07FFDA4F36F82h) 
                    c->setActiveDisplays(displays);
00007FFDA504E194  mov         rcx,qword ptr [c] 
00007FFDA504E19C  call        boost::shared_ptr<OpenColorIO::v1::Config>::operator-> (07FFDA4F33972h) 
00007FFDA504E1A1  mov         rdx,qword ptr [rsp+0C58h] 
00007FFDA504E1A9  mov         rcx,rax 
00007FFDA504E1AC  call        OpenColorIO::v1::Config::setActiveDisplays (07FFDA4F33323h) 


Hopefully this displays OK for you.
You can see just before the c->setActiveDisplays(displays) the string destructor fires.
So the pointer passed to setActiveDisplay is thus now pointing to freed memory ....

This kind of makes sense - the scope is just for the return value as the object is not assigned to anything (the *contents* are, the c_str, but std::string doesn't reference count that!) but I suspect some compilers aren't so eager to destroy the returned string as Visual Studio 2012 ....


Simon.



On Wednesday, July 23, 2014 12:55:30 AM UTC+1, Mark Boorer wrote:
Hi Simon,

Not sure I see where a bug could be hiding. The scoping around those blocks seems fine to me.
setActiveDisplays(), though taking a const char * as an argument, never actually stores it internally, instead opting to store the results of another call to SplitStringEnvStyle().

SplitStringEnvStyle() makes a new std::string via pystring::strip as one of its first operations, so there is no possibility of char pointers falling out of scope.

This has been fairly stable code (since around 2011), though admittedly OCIOYaml.cpp has recently undergone some changes.

Would you happen to have some more information as to your development environment? Visual Studio / OCIO versions / ways to reproduce the crash you're seeing?

With a little more information I'll hopefully be able to root out the cause of the issue.

Cheers,
Mark


On Tue, Jul 22, 2014 at 4:03 PM, simon smith <si.c...@...> wrote:
I'm testing out some code and I've noticed a crash issue when a config (such as ACES, from the ICIO website) contain multiple active displays or views.

Basically, the code in ICIOYaml.cpp that takes an array of displays tries to join them together into one string using the JoinStringEnvStyle function (in ParseUtils.cpp) is flawed.

JoinStringEnvStyle will return a new std::string instance if more than one string is found in the array (it will pass the original "array" string back if there is only one entry in it).

The caller of JoinStringEnvStylein OCIOYaml.cpp takes a const pointer to this returned std::string to pass to the next function (setActiveDisplays) but it falls out of scope as soon as the const char* has been taken (it goes out of scope as it enters the next line of code). Thus on the next line the pointer is pointing to freed memory. You probably get away with this in release, but in debug (under windows) it will write freed memory markers as guards for this type of thing.

The code currently is:

std::vector<std::string> display;
load(second, display);
const char* displays = JoinStringEnvStyle(display).c_str();
c->setActiveDisplays(displays);

You can easily see the scope issue here.
I suspect a fix would be along the lines of:

std::vector<std::string> display;
load(second, display);
std::string strDisplays = JoinStringEnvStyle(display).c_str();
const char* displays = strDisplays.c_str();
c->setActiveDisplays(displays);

I thought I'd pass this on as I've not seen any notes on it anywhere, but it must be an issue for everyone.


 - Simon.

--
You received this message because you are subscribed to the Google Groups "OpenColorIO Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ocio-dev+u...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Re: Nuke colorconfig - View "None" is "raw" in OCIO

mikael....@...
 

"This applies only to non-linear input colorspaces" => not non-linear, all colorspaces except Linear.

Den onsdagen den 23:e juli 2014 kl. 09:07:28 UTC+2 skrev mikae...@...:

Not really - it happens outside Nuke using the ocio GPU support:

OCIO::DisplayTransform::create()
displayTransform->setInputColorSpace( "sRGB" )
displayTransform->setDisplay( "display" )
displayTransform->setView( "None" )
+ LUT data and GPU shader generation

This applies only to non-linear input colorspaces, if None is set as view then the input colorspace will not transformed to linear, right?

I modified the Nuke profile:

displays:
  default:
    - !<View> {name: None, colorspace: linear} <= instead of raw

To match the viewerProcess drop-down in nuke. With this setup you'll get a linear representation if None is used as view (in this example sRGB => linear).

I may not be right here :-) but I hope so. Guess it's more of a question about when the actual color transformation happens in nuke and ocio.

Mikael


Den onsdagen den 23:e juli 2014 kl. 01:33:31 UTC+2 skrev Mark Boorer:
Hi Mikael,

Just trying to see if I'm understanding your issue correctly. When using the OCIO Display node inside of Nuke (with the OCIO environment variable pointing to the nuke-default/config.ocio and the viewer transform set to "None") You are getting "raw" as the default input colorspace?

Would you mind letting me know the versions of Nuke / OCIO / OpenColorIO-Configs you are using?

At the moment, I can't seem to replicate the issue on Nuke8.0v5, with libOpenColorIO.so.1.0.7, and using the master branch of OpenColorIO-Configs. I see "linear" by default as expected.

Cheers,
Mark




On Tue, Jul 22, 2014 at 10:21 AM, <mikae...@...> wrote:
I'm doing automated slap-comps to check render output in sRGB/Cineon and scene-linear, if I use the nuke profile and "None" as the view for the default display the profile returns "raw". It should be linear to match Nuke, right?
Mikael

--
You received this message because you are subscribed to the Google Groups "OpenColorIO Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ocio-d...@....
For more options, visit https://groups.google.com/d/optout.


Re: Nuke colorconfig - View "None" is "raw" in OCIO

mikael....@...
 

Not really - it happens outside Nuke using the ocio GPU support:

OCIO::DisplayTransform::create()
displayTransform->setInputColorSpace( "sRGB" )
displayTransform->setDisplay( "display" )
displayTransform->setView( "None" )
+ LUT data and GPU shader generation

This applies only to non-linear input colorspaces, if None is set as view then the input colorspace will not transformed to linear, right?

I modified the Nuke profile:

displays:
  default:
    - !<View> {name: None, colorspace: linear} <= instead of raw

To match the viewerProcess drop-down in nuke. With this setup you'll get a linear representation if None is used as view (in this example sRGB => linear).

I may not be right here :-) but I hope so. Guess it's more of a question about when the actual color transformation happens in nuke and ocio.

Mikael


Den onsdagen den 23:e juli 2014 kl. 01:33:31 UTC+2 skrev Mark Boorer:

Hi Mikael,

Just trying to see if I'm understanding your issue correctly. When using the OCIO Display node inside of Nuke (with the OCIO environment variable pointing to the nuke-default/config.ocio and the viewer transform set to "None") You are getting "raw" as the default input colorspace?

Would you mind letting me know the versions of Nuke / OCIO / OpenColorIO-Configs you are using?

At the moment, I can't seem to replicate the issue on Nuke8.0v5, with libOpenColorIO.so.1.0.7, and using the master branch of OpenColorIO-Configs. I see "linear" by default as expected.

Cheers,
Mark




On Tue, Jul 22, 2014 at 10:21 AM, <mikae...@...> wrote:
I'm doing automated slap-comps to check render output in sRGB/Cineon and scene-linear, if I use the nuke profile and "None" as the view for the default display the profile returns "raw". It should be linear to match Nuke, right?
Mikael

--
You received this message because you are subscribed to the Google Groups "OpenColorIO Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ocio-dev+u...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Re: Crash issue having multiple active_displays in a config

Mark Boorer <mark...@...>
 

Hi Simon,

Not sure I see where a bug could be hiding. The scoping around those blocks seems fine to me.
setActiveDisplays(), though taking a const char * as an argument, never actually stores it internally, instead opting to store the results of another call to SplitStringEnvStyle().

SplitStringEnvStyle() makes a new std::string via pystring::strip as one of its first operations, so there is no possibility of char pointers falling out of scope.

This has been fairly stable code (since around 2011), though admittedly OCIOYaml.cpp has recently undergone some changes.

Would you happen to have some more information as to your development environment? Visual Studio / OCIO versions / ways to reproduce the crash you're seeing?

With a little more information I'll hopefully be able to root out the cause of the issue.

Cheers,
Mark


On Tue, Jul 22, 2014 at 4:03 PM, simon smith <si.c....@...> wrote:
I'm testing out some code and I've noticed a crash issue when a config (such as ACES, from the ICIO website) contain multiple active displays or views.

Basically, the code in ICIOYaml.cpp that takes an array of displays tries to join them together into one string using the JoinStringEnvStyle function (in ParseUtils.cpp) is flawed.

JoinStringEnvStyle will return a new std::string instance if more than one string is found in the array (it will pass the original "array" string back if there is only one entry in it).

The caller of JoinStringEnvStylein OCIOYaml.cpp takes a const pointer to this returned std::string to pass to the next function (setActiveDisplays) but it falls out of scope as soon as the const char* has been taken (it goes out of scope as it enters the next line of code). Thus on the next line the pointer is pointing to freed memory. You probably get away with this in release, but in debug (under windows) it will write freed memory markers as guards for this type of thing.

The code currently is:

std::vector<std::string> display;
load(second, display);
const char* displays = JoinStringEnvStyle(display).c_str();
c->setActiveDisplays(displays);

You can easily see the scope issue here.
I suspect a fix would be along the lines of:

std::vector<std::string> display;
load(second, display);
std::string strDisplays = JoinStringEnvStyle(display).c_str();
const char* displays = strDisplays.c_str();
c->setActiveDisplays(displays);

I thought I'd pass this on as I've not seen any notes on it anywhere, but it must be an issue for everyone.


 - Simon.

--
You received this message because you are subscribed to the Google Groups "OpenColorIO Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ocio-dev+u...@....
For more options, visit https://groups.google.com/d/optout.

861 - 880 of 2227