OK, I think I understand what's going on. Let me look at it and I'll suggest a
patch.
-- lg
On Jul 7, 2014, at 10:38 PM, Pete Black <pbl...@parkroad.co.nz> wrote:
> Hi Larry,
>
> Ah, I rebuilt with full debug, and now it seems libOpenEXR is throwing an
> exception:
>
> Caught OpenEXR exception: Cannot assign a value of type "string" to image
> attribute "multiView" of type "stringvector".
> Don't know what to do with string multiView
>
> this is using the below:
>
>>>>>>>>>> const char * vals[2]={“right”,”left”};
>>>>>>>>>> OIIO::TypeDesc multiViewAttr (OIIO::TypeDesc::STRING,2); // array
>>>>>>>>>> of 2 strings
>>>>>>>>>> outputImageSpec.attribute("multiView",multiViewAttr,vals);
>
> cut n pasted right out of this discussion.
>
>
> wierd it seems to work fine with the same OIIO and same OpenEXR on Linux
>
> exrheader /tmp/out.000010.sxr
>
>> /tmp/out.000010.sxr:
>>
>>
>>
>>
>> file format version: 2, flags 0x0
>>
>>
>>
>> NumFrames (type int): 62
>>
>>
>>
>> TapeName (type string): "2013869"
>>
>>
>>
>> TimeCode (type string): "01:00:00:22"
>>
>>
>>
>> capDate (type string): "2014:07:08 17:36:26"
>>
>>
>>
>> channels (type chlist):
>>
>>
>>
>> B, 16-bit floating-point, sampling 1 1
>>
>>
>>
>> G, 16-bit floating-point, sampling 1 1
>>
>>
>>
>> R, 16-bit floating-point, sampling 1 1
>>
>>
>>
>> right.B, 16-bit floating-point, sampling 1 1
>>
>>
>>
>> right.G, 16-bit floating-point, sampling 1 1
>>
>>
>>
>> right.R, 16-bit floating-point, sampling 1 1
>>
>>
>>
>> compression (type compression): zip, individual scanlines
>>
>>
>>
>> dataWindow (type box2i): (0 0) - (2047 1151)
>>
>>
>>
>> displayWindow (type box2i): (0 0) - (2047 1151)
>>
>>
>>
>> lineOrder (type lineOrder): increasing y
>> multiView (type stringvector):
>> "right"
>> "left"
>> pixelAspectRatio (type float): 1
>> screenWindowCenter (type v2f): (0 0)
>> screenWindowWidth (type float): 1
>> type (type string): "scanlineimage"
>>
>
>
> Thanks
>
> -Pete
>
>
>
>
>
> On 8/07/2014, at 5:20 pm, Larry Gritz <l...@larrygritz.com> wrote:
>
>> I'm upgrading my xcode in the hopes of giving me the same version of clang
>> that you have, we'll see what happens.
>>
>> It's not clear if it's a clang bug, or if it's a bug in OIIO (or your code)
>> that just happens to only be symptomatic with certain compiler versions.
>> I'll keep you posted.
>>
>> -- lg
>>
>>
>> On Jul 7, 2014, at 10:18 PM, Pete Black <pbl...@parkroad.co.nz> wrote:
>>
>>> Hi Larry,
>>>
>>> Thats odd, AFAIK I just upgraded to Mavericks from mountain lion, and thats
>>> what showed up on my system - I did run some kind of xcode-select command
>>> to install some stuff that seemed to be misisng, but I haven’t been
>>> installing betas.
>>>
>>> http://en.wikipedia.org/wiki/Xcode indicates that verison of clang is
>>> current, for Xcode 5.1.1 (5B1008)
>>>
>>> It is very possible the version of clang shipped is buggy in some way - the
>>> Apple gcc/clang switcheroo has not been a good experience for me thus far,
>>> but it could be worse. It could be Windows. Anyway, I digress.
>>>
>>> I do have brew installed, but I am not really super keen to go messing with
>>> my environment too much right now, as I need this mac to build tools that
>>> will run on our wranglers’ machines.
>>>
>>> I’m quite happy with my ‘parse comma-separated-values into stringvectors’
>>> solution for the moment, and I guess bugs such as this will shake out over
>>> time.
>>>
>>> I will attempt to do a full debug build and gather more information for you
>>> when I get a chance.
>>>
>>> Thanks
>>>
>>> -Pete
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> On 8/07/2014, at 5:04 pm, Larry Gritz <l...@larrygritz.com> wrote:
>>>
>>>> Which xcode are you using? The xcode 6 beta?
>>>>
>>>> I have the stock xcode 5 and I have a different version of clang:
>>>>
>>>> $ clang --version
>>>> Apple LLVM version 5.0 (clang-500.2.79) (based on LLVM 3.3svn)
>>>> Target: x86_64-apple-darwin13.3.0
>>>>
>>>> You seem to have a "newer" clang, I wonder if that's buggy in some way?
>>>>
>>>> Can you make a full debug build of OIIO and try again, so that the
>>>> backtrace gives line numbers as well?
>>>>
>>>> Do you have a Homebrew or MacPorts installation? I'm wondering what would
>>>> happen if you compiled OIIO with a fully modern "release" clang rather
>>>> than the slightly odd version that ships with xcode.
>>>>
>>>>
>>>>
>>>> On Jul 6, 2014, at 7:48 PM, Pete Black <pbl...@parkroad.co.nz> wrote:
>>>>
>>>>> Hi Larry,
>>>>>
>>>>> OpenEXR 2.1.0, and whatever the default compiler version on OS X is now:
>>>>>
>>>>> gcc --version
>>>>> Configured with: --prefix=/Applications/Xcode.app/Contents/Developer/usr
>>>>> --with-gxx-include-dir=/usr/include/c++/4.2.1
>>>>> Apple LLVM version 5.1 (clang-503.0.40) (based on LLVM 3.4svn)
>>>>> Target: x86_64-apple-darwin13.2.0
>>>>>
>>>>>
>>>>> On Linux, the same verison of openEXR compiles and works fine, resulting
>>>>> in my multiview attribute being present.
>>>>>
>>>>> running it through lldb with a breakpoint set on malloc_error_break:
>>>>>
>>>>>
>>>>> (lldb) bt
>>>>> * thread #1: tid = 0x18d8ab, 0x00007fff8c412050
>>>>> libsystem_platform.dylib`_platform_memmove$VARIANT$Nehalem + 112, queue =
>>>>> 'com.apple.main-thread', stop reason = EXC_BAD_ACCESS
>>>>> (code=EXC_I386_GPFLT)
>>>>> * frame #0: 0x00007fff8c412050
>>>>> libsystem_platform.dylib`_platform_memmove$VARIANT$Nehalem + 112
>>>>> frame #1: 0x00007fff8988be36 libc++.1.dylib`std::__1::basic_string<char,
>>>>> std::__1::char_traits<char>, std::__1::allocator<char> >::__init(char
>>>>> const*, unsigned long) + 96
>>>>> frame #2: 0x0000000101073c22 libOpenImageIO.1.5.dylib`void
>>>>> std::__1::vector<std::__1::basic_string<char,
>>>>> std::__1::char_traits<char>, std::__1::allocator<char> >,
>>>>> std::__1::allocator<std::__1::basic_string<char,
>>>>> std::__1::char_traits<char>, std::__1::allocator<char> > >
>>>>> >::__push_back_slow_path<std::__1::basic_string<char,
>>>>> std::__1::char_traits<char>, std::__1::allocator<char> >
>>>>> const>(std::__1::basic_string<char, std::__1::char_traits<char>,
>>>>> std::__1::allocator<char> > const&) + 258
>>>>> frame #3: 0x00000001015ef5be
>>>>> libOpenImageIO.1.5.dylib`OpenImageIO::v1_5::OpenEXROutput::put_parameter(std::__1::basic_string<char,
>>>>> std::__1::char_traits<char>, std::__1::allocator<char> > const&,
>>>>> OpenImageIO::v1_5::TypeDesc, void const*, Imf_2_1::Header&) + 12766
>>>>> frame #4: 0x00000001015eb7e6
>>>>> libOpenImageIO.1.5.dylib`OpenImageIO::v1_5::OpenEXROutput::spec_to_header(OpenImageIO::v1_5::ImageSpec&,
>>>>> int, Imf_2_1::Header&) + 2854
>>>>> frame #5: 0x00000001015ea8c5
>>>>> libOpenImageIO.1.5.dylib`OpenImageIO::v1_5::OpenEXROutput::open(std::__1::basic_string<char,
>>>>> std::__1::char_traits<char>, std::__1::allocator<char> > const&,
>>>>> OpenImageIO::v1_5::ImageSpec const&,
>>>>> OpenImageIO::v1_5::ImageOutput::OpenMode) + 693
>>>>> frame #6: 0x000000010007ef42 PRIOnCLI`PRIOSXRSequenceOutputNode::update()
>>>>> + 7554
>>>>> frame #7: 0x000000010000a937 PRIOnCLI`PRIOGraph::execute() + 759
>>>>> frame #8: 0x000000010000457f PRIOnCLI`CLIGraph::run() + 3519
>>>>> frame #9: 0x0000000101be3d61 QtCore`QObject::event(QEvent*) + 1073
>>>>> frame #10: 0x0000000101bd03bf
>>>>> QtCore`QCoreApplicationPrivate::notify_helper(QObject*, QEvent*) + 95
>>>>> frame #11: 0x0000000101bd0715 QtCore`QCoreApplication::notify(QObject*,
>>>>> QEvent*) + 53
>>>>> frame #12: 0x0000000101bd053c
>>>>> QtCore`QCoreApplication::notifyInternal(QObject*, QEvent*) + 124
>>>>> frame #13: 0x0000000101bd12a0
>>>>> QtCore`QCoreApplicationPrivate::sendPostedEvents(QObject*, int,
>>>>> QThreadData*) + 896
>>>>> frame #14: 0x0000000101c048c2
>>>>> QtCore`QEventDispatcherUNIX::processEvents(QFlags<QEventLoop::ProcessEventsFlag>)
>>>>> + 66
>>>>> frame #15: 0x0000000101bcf454
>>>>> QtCore`QEventLoop::processEvents(QFlags<QEventLoop::ProcessEventsFlag>) +
>>>>> 68
>>>>> frame #16: 0x0000000101bcf804
>>>>> QtCore`QEventLoop::exec(QFlags<QEventLoop::ProcessEventsFlag>) + 324
>>>>> frame #17: 0x0000000101bd178a QtCore`QCoreApplication::exec() + 186
>>>>> frame #18: 0x0000000100004bd3 PRIOnCLI`main + 115
>>>>> frame #19: 0x00000001000037b4 PRIOnCLI`start + 52
>>>>>
>>>>>
>>>>>
>>>>> Thanks
>>>>>
>>>>> -Pete
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> On 7/07/2014, at 2:33 pm, Larry Gritz <l...@larrygritz.com> wrote:
>>>>>
>>>>>> Weird!
>>>>>>
>>>>>> I'll try on my end. Which version of OpenEXR are you using? And which
>>>>>> compiler?
>>>>>>
>>>>>>
>>>>>>
>>>>>> On Jul 6, 2014, at 7:30 PM, Pete Black <pbl...@parkroad.co.nz> wrote:
>>>>>>
>>>>>>> Hi Larry,
>>>>>>>
>>>>>>> The code below compiles OK, but produces a segfault accompanied by this
>>>>>>> lovely error:
>>>>>>>
>>>>>>>> PRIOnCLI(19771,0x7fff75b09310) malloc: ***
>>>>>>>> mach_vm_map(size=140425929424896) failed (error code=3)
>>>>>>>> *** error: can't allocate region
>>>>>>>> *** set a breakpoint in malloc_error_break to debug
>>>>>>>>
>>>>>>>
>>>>>>> It seems to me this may actually be a bug in mavericks (looks like some
>>>>>>> kind of string zero-termination-related overrun) as I have seen similar
>>>>>>> issues reported on google by other projects when attempting to figure
>>>>>>> this out.
>>>>>>>
>>>>>>> Probably not super-helpful, but let me know if there is anything else
>>>>>>> you would like me to try?
>>>>>>>
>>>>>>> Thanks
>>>>>>>
>>>>>>> -Pete
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> On 7/07/2014, at 2:18 pm, Larry Gritz <l...@larrygritz.com> wrote:
>>>>>>>
>>>>>>>> OK, I'm expecting it to accept the "array of 2 strings" but not VEC2
>>>>>>>> of string. But I still wouldn't want that to crash.
>>>>>>>>
>>>>>>>> Check both ways and let me know of, all else being ok, this one thing
>>>>>>>> makes it crash, and that points to something else for me to fix.
>>>>>>>>
>>>>>>>> -- lg
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> On Jul 6, 2014, at 7:16 PM, Pete Black <pbl...@parkroad.co.nz> wrote:
>>>>>>>>
>>>>>>>>> Hi Larry,
>>>>>>>>>
>>>>>>>>> I’ll give that a try - pretty sure i tried it with const char* as
>>>>>>>>> well and it still segfaulted on Mavericks but possibly it is the VEC2
>>>>>>>>> thing causing this problem.
>>>>>>>>>
>>>>>>>>> Thanks,
>>>>>>>>>
>>>>>>>>> -Pete
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>> Just change to
>>>>>>>>>>
>>>>>>>>>> const char * vals[2]={“right”,”left”};
>>>>>>>>>> OIIO::TypeDesc multiViewAttr (OIIO::TypeDesc::STRING,2); // array
>>>>>>>>>> of 2 strings
>>>>>>>>>> outputImageSpec.attribute("multiView",multiViewAttr,vals);
>>>>>>>>>>
>>>>>>>>>> The data you pass back and forth as a "string" is a char*, not
>>>>>>>>>> actually a std::string. And I recommend passing it as an array of 2
>>>>>>>>>> strings (as I have above) rather than a VEC2 (which is subtly
>>>>>>>>>> different, and almost always used for numeric vector types).
>>>>>>>>>>
>>>>>>>>>> Let me know if this works.
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> On Jul 6, 2014, at 6:52 PM, Pete Black <pbl...@parkroad.co.nz> wrote:
>>>>>>>>>>
>>>>>>>>>>> Hi All,
>>>>>>>>>>>
>>>>>>>>>>> just after some clarification on some issues I have had recently.
>>>>>>>>>>>
>>>>>>>>>>> I need to create a StringVector metadata entry in EXR files (for
>>>>>>>>>>> stereo EXRs, the ‘MultiView’ attribute)
>>>>>>>>>>>
>>>>>>>>>>> I was using (abusing?) OIIO to do something like:
>>>>>>>>>>>
>>>>>>>>>>> std::string vals[2]={“right”,”left”};
>>>>>>>>>>> OpenImageIO::TypeDesc
>>>>>>>>>>> multiViewAttr=OpenImageIO::TypeDesc(OpenImageIO::TypeDesc::STRING,OpenImageIO::TypeDesc::VEC2);
>>>>>>>>>>> outputImageSpec.attribute("multiView",multiViewAttr,vals);
>>>>>>>>>>>
>>>>>>>>>>> And this seemed to work on Linux. Possibly it worked by chance,
>>>>>>>>>>> rather than by design, given that:
>>>>>>>>>>>
>>>>>>>>>>> When porting my code to OS X Mavericks (Clang,libc++ and other
>>>>>>>>>>> painful changes), this piece of code compiled, but caused segfaults
>>>>>>>>>>> in my app at runtime.
>>>>>>>>>>>
>>>>>>>>>>> I note there is some attribute processing code which (it is a bit
>>>>>>>>>>> tricky to follow, uses OIIOs internal string reference stuff) seems
>>>>>>>>>>> to indicate that attribute setting on an ImageSpec is probably only
>>>>>>>>>>> *supposed* to work with a single string value.
>>>>>>>>>>>
>>>>>>>>>>> I since rewrote things to extend the openexr output plugin to take
>>>>>>>>>>> single-string attributes with a ‘csv’ prefix (i.e. common-separated
>>>>>>>>>>> values) and expand them into StringVector attributes on write,
>>>>>>>>>>> which works fine cross-platform, but obviously I needed to modify
>>>>>>>>>>> the exroutput plugin to make this work, and is a bit of a hack.
>>>>>>>>>>>
>>>>>>>>>>> Is there a ‘right way’ to do this that I have just managed to miss?
>>>>>>>>>>>
>>>>>>>>>>> Thanks,
>>>>>>>>>>>
>>>>>>>>>>> -Pete
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> _______________________________________________
>>>>>>>>>>> Oiio-dev mailing list
>>>>>>>>>>> Oiio-dev@lists.openimageio.org
>>>>>>>>>>> http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org
>>>>>>>>>>
>>>>>>>>>> --
>>>>>>>>>> Larry Gritz
>>>>>>>>>> l...@larrygritz.com
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> _______________________________________________
>>>>>>>>>> Oiio-dev mailing list
>>>>>>>>>> Oiio-dev@lists.openimageio.org
>>>>>>>>>> http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org
>>>>>>>>>
>>>>>>>>> _______________________________________________
>>>>>>>>> Oiio-dev mailing list
>>>>>>>>> Oiio-dev@lists.openimageio.org
>>>>>>>>> http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org
>>>>>>>>
>>>>>>>> --
>>>>>>>> Larry Gritz
>>>>>>>> l...@larrygritz.com
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> _______________________________________________
>>>>>>>> Oiio-dev mailing list
>>>>>>>> Oiio-dev@lists.openimageio.org
>>>>>>>> http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org
>>>>>>>
>>>>>>> _______________________________________________
>>>>>>> Oiio-dev mailing list
>>>>>>> Oiio-dev@lists.openimageio.org
>>>>>>> http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org
>>>>>>
>>>>>> --
>>>>>> Larry Gritz
>>>>>> l...@larrygritz.com
>>>>>>
>>>>>>
>>>>>>
>>>>>> _______________________________________________
>>>>>> Oiio-dev mailing list
>>>>>> Oiio-dev@lists.openimageio.org
>>>>>> http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org
>>>>>
>>>>> _______________________________________________
>>>>> Oiio-dev mailing list
>>>>> Oiio-dev@lists.openimageio.org
>>>>> http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org
>>>>
>>>> --
>>>> Larry Gritz
>>>> l...@larrygritz.com
>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> Oiio-dev mailing list
>>>> Oiio-dev@lists.openimageio.org
>>>> http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org
>>>
>>> _______________________________________________
>>> Oiio-dev mailing list
>>> Oiio-dev@lists.openimageio.org
>>> http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org
>>
>> --
>> Larry Gritz
>> l...@larrygritz.com
>>
>>
>>
>> _______________________________________________
>> Oiio-dev mailing list
>> Oiio-dev@lists.openimageio.org
>> http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org
>
> _______________________________________________
> Oiio-dev mailing list
> Oiio-dev@lists.openimageio.org
> http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org
--
Larry Gritz
l...@larrygritz.com
_______________________________________________
Oiio-dev mailing list
Oiio-dev@lists.openimageio.org
http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org
