Right, when it accesses the characters in the callee, it fails for some reason.
So the additional line I wanted to add prints the address of the characters,
before trying to access them. I want to know if the caller and callee disagree
on *where* those characters are in memory, or are they both looking at the same
memory but for some other reason the callee can't touch them?
Oh, one more!
std::cout << "str addr = " << (void*)&str << std::endl;
std::cout << "str len " << str.size() << std::endl;
std::cout << "str char addr = " << (void*)str.c_str() << std::endl;
std::cout << "str first char = " << int(str[0]) << std::endl;
std::cout << "str chars = '" << str << "'" << std::endl;
Can it access the first character, or is it "running off the end of the
string", so to speak, when it fails.
> On Apr 25, 2019, at 11:52 AM, Mathieu Prevot <[email protected]> wrote:
>
> In the callee, whatever I try to do it throws.
> Hence I know I'll get something from my code, and nothing from oiio function.
> I tried to ask a local copy of str, it just throws at `string localstr = str;`
>
> I think it should be wiser to pass string by value and not by reference.
>
> Any thought, objection ?
> M
>
> Le jeu. 25 avr. 2019 à 20:43, Larry Gritz <[email protected]
> <mailto:[email protected]>> a écrit :
> Hmmm. OK, one more test:
>
> In both of the places (caller and callee), can you add one more line in this
> spot:
>
> std::cout << "str addr = " << (void*)&str << std::endl;
> std::cout << "str len " << str.size() << std::endl;
> std::cout << "str char addr = " << (void*)str.c_str() << std::endl;
> std::cout << "str chars = '" << str << "'" << std::endl;
>
> ???
>
>
>
>> On Apr 25, 2019, at 10:36 AM, Mathieu Prevot <[email protected]
>> <mailto:[email protected]>> wrote:
>>
>> The output with the modified sources as you requested:
>>
>> filename2 addr = 000000C9E28FF930
>> filename2 len = 79
>> filename2 =
>> 'C:/sensomovie/C200/A011C118_19041345_CANON/A011C118_19041345_CANON_00002043.DPX'
>> str addr = 000000C9E28FF930
>> str len 79
>> str chars = '
>>
>> Access violation reading location 0xFFFFFFFFFFFFFFFE
>>
>> It seems it complains about being/not able to read the string, even though
>> the address and length are correct.
>>
>> M
>>
>>
>> Le jeu. 25 avr. 2019 à 18:51, Larry Gritz <[email protected]
>> <mailto:[email protected]>> a écrit :
>> So that minimal example also fails?
>>
>> Did you add those extra printf lines on the OIIO side that I suggested a
>> couple messages ago? What did they print?
>>
>> OK, next experiment:
>>
>> Copy those lines inside main() from my minimal example below, and paste them
>> into OIIO src/info/iinfo.cpp, right in its main() before it does anything
>> else. The point of this test is to see what happens when we are absolutely
>> sure that the program calling this sequence is built with all the same
>> compile flags and headers as the OSL library itself. Then build OIIO in
>> whatever configuration was producing failures reliably before, and try by
>> running "iinfo" (it's not the "real" iinfo now, it's just a harness for
>> running that minimal example). What happens, and what does it print with
>> those debugging statements?
>>
>>
>>
>>> On Apr 25, 2019, at 6:44 AM, Mathieu Prevot <[email protected]
>>> <mailto:[email protected]>> wrote:
>>>
>>> In the oiioTest project, there is no test framework, no specific c++
>>> standard is specified (an noe was specified at oiio build).
>>> I'm using v141 toolset in both (the default VS2017 toolset).
>>> The truly minimal program fails too.
>>> Can you use the source and script I provided to reproduce the memory error ?
>>>
>>> M
>>>
>>>
>>> Le mer. 24 avr. 2019 à 23:59, Larry Gritz <[email protected]
>>> <mailto:[email protected]>> a écrit :
>>> That's interesting. Definitely makes me think it's some kind of mismatch
>>> between your module and OIIO, since the all-OIIO code (using oiiotool,
>>> which calls the same libOpenImageIO APIs underneath) seems fine.
>>>
>>> Are you sure that OIIO and your code was definitely built with the same
>>> compiler version? Same flags indicating the C++ standard to use or any
>>> other such things that may be relevant for MSVS?
>>>
>>> What I would recommend next is trying to find the *minimal*
>>> separately-compiled program that exhibits the problem. Eliminate your
>>> testing framework and all other cruft. Would the following truly minimal
>>> program also fail?
>>>
>>> #include <OpenImageIO/imageio.h>
>>> int main (int argc, char *argv[]);
>>> {
>>> const char* filename =
>>> "C:\sensomovie\C200\A011C118_19041345_CANON\A011C118_19041345_CANON_00000001.DPX"
>>> auto in = ImageInput::open(filename);
>>> if (in) {
>>> printf ("Opened successfully\n");
>>> printf ("Opened successfully, format is %s\n", in->format_name());
>>> } else {
>>> printf ("Fail\n");
>>> return 1;
>>> }
>>> return 0;
>>> }
>>>
>>>
>>>> On Apr 24, 2019, at 2:27 PM, Mathieu Prevot <[email protected]
>>>> <mailto:[email protected]>> wrote:
>>>>
>>>> No, it only crashes when I use the API in release, I use the API in debug
>>>> it works too. The output:
>>>>
>>>> .\oiiotool.exe -info -v
>>>> C:\sensomovie\C200\A011C118_19041345_CANON\A011C118_19041345_CANON_00000001.
>>>> DPX
>>>> Reading
>>>> C:\sensomovie\C200\A011C118_19041345_CANON\A011C118_19041345_CANON_00000001.DPX
>>>> C:\sensomovie\C200\A011C118_19041345_CANON\A011C118_19041345_CANON_00000001.DPX
>>>> : 4096 x 2160, 3 channel, uint10 dpx
>>>> channel list: R, G, B
>>>> DateTime: "2019:04:13 16:14:30"
>>>> Orientation: 1 (normal)
>>>> PixelAspectRatio: 1
>>>> Software: "CANON"
>>>> dpx:Colorimetric: "Unspecified video"
>>>> dpx:DittoKey: 1
>>>> dpx:EndOfImagePadding: 0
>>>> dpx:EndOfLinePadding: 0
>>>> dpx:FramePosition: 1
>>>> dpx:FrameRate: 59.9401
>>>> dpx:HeldCount: 1
>>>> dpx:ImageDescriptor: "RGB"
>>>> dpx:InputDeviceSerialNumber: "373449900026"
>>>> dpx:Interlace: 0
>>>> dpx:Packing: "Filled, method A"
>>>> dpx:SequenceLength: 2931
>>>> dpx:ShutterAngle: 0
>>>> dpx:SourceDateTime: "2019:04:13 16:14:30"
>>>> dpx:SourceImageFileName: "A011C118_19041345_CANON.CRM"
>>>> dpx:TemporalFrameRate: 59.9401
>>>> dpx:TimeCode: "00:42:11;23"
>>>> dpx:Transfer: "Unspecified video"
>>>> dpx:UserBits: 0
>>>> dpx:UserData: 67, 65, 78, 79, 78, 95, 82, 65, 87, 95, 68, 69, 86, 69,
>>>> 76, 79, ... [63488 x uint8]
>>>> dpx:Version: "V2.0"
>>>> oiio:BitsPerSample: 10
>>>> smpte:TimeCode: 00:42:11:23
>>>>
>>>> Mathieu
>>>>
>>>> Le mer. 24 avr. 2019 à 23:24, Larry Gritz <[email protected]
>>>> <mailto:[email protected]>> a écrit :
>>>> Matthieu, can you confirm:
>>>>
>>>> * Does `oiiotool -info -v yourfile.dpx` also crash (with the same filename
>>>> as you used before, of course)? Or does it only crash when the OIIO API
>>>> calls are made from your program?
>>>>
>>>>
>>>>
>>>>> On Apr 24, 2019, at 1:51 PM, Mathieu Prevot <[email protected]
>>>>> <mailto:[email protected]>> wrote:
>>>>>
>>>>> Hello. Many thanks Till for your previous posts and proposition.
>>>>>
>>>>> I'm curious to know if the problems can be reproduced.
>>>>> Here are the binaries of oiio, openexr and few dependencies, as well as
>>>>> their source and the powershell script I use to configure/build/install
>>>>> those libraries.
>>>>> There is also the oiioTest project which I use to open the DPX 10bits
>>>>> image.
>>>>> The debug and release configuration are those I used to far. The debug
>>>>> should work and the release should trigger the memory exception, at least
>>>>> certainly when you ask to inline whenever possible.
>>>>> I'm using boost 1.70, the available for download binaries. Everything in
>>>>> x64.
>>>>>
>>>>> https://1drv.ms/f/s!AlUmbfQiLoTZhFUTthzeUkWoB3rc
>>>>> <https://1drv.ms/f/s!AlUmbfQiLoTZhFUTthzeUkWoB3rc>
>>>>>
>>>>> I built the libraries with the v141 toolset (the latest that comes with
>>>>> VS2017; it also comes with VS2019).
>>>>> I built the oiioTest with v142 as well as v141, and I observed the same
>>>>> result in both cases.
>>>>> I'll do them again to be certain.
>>>>> I'll try Larry's patches to get to know more, and then post here again.
>>>>>
>>>>> I'll also try Till's binaries, but I can tell already that those binaries
>>>>> are missing:
>>>>> RAW_R.DLL (?)
>>>>> BOOST_FILESYSTEM-VC141-MT-X64-1_66.DLL (no problem to get those boost
>>>>> libraries)
>>>>> BOOST_THREAD-VC141-MT-X64-1_66.DLL
>>>>> LZMA.DLL (?)
>>>>> Maybe a script would be easier to use than binaries.
>>>>>
>>>>> M
>>>>>
>>>>>
>>>>> Le mer. 24 avr. 2019 à 20:30, till dechent <[email protected]
>>>>> <mailto:[email protected]>> a écrit :
>>>>> My guess would be that VS2019 being the problem is unlikely since Mathieu
>>>>> also tried with the vs141 toolset.
>>>>>
>>>>> To narrow things down between a compile issue and a code issue you could
>>>>> grab my binaries and see if your code works with them:
>>>>> https://github.com/ttddee/oiio-msvc2017
>>>>> <https://github.com/ttddee/oiio-msvc2017>
>>>>>
>>>>> Or maybe try a build without the command line and go straight from CMake
>>>>> to Visual Studio to compile from there.
>>>>>
>>>>> I have a Windows machine here so if you need me to try anything, happy to
>>>>> help!
>>>>>
>>>>>
>>>>>
>>>>> Am Mi., 24. Apr. 2019 um 18:41 Uhr schrieb Larry Gritz
>>>>> <[email protected] <mailto:[email protected]>>:
>>>>> I'm sorry to ask you to be my debugging robot, but since I can't seem to
>>>>> reproduce on my end...
>>>>>
>>>>>
>>>>> So let's try another thing. At the call site,
>>>>>
>>>>> std::cout << "reading (float) file: " << filename << "\n";
>>>>> string filename2 = filename;
>>>>> std::cout << "filename2 addr = " << (void*)&filename2 << std::endl;
>>>>> std::cout << "filename2 len = " << filename2.size() << std::endl;
>>>>> std::cout << "filename2 = '" << filename2 << "'\n";
>>>>> auto in = ImageInput::open(filename2);
>>>>>
>>>>> And inside get_rest_arguments:
>>>>>
>>>>> bool
>>>>> Strutil::get_rest_arguments(const std::string& str, std::string& base,
>>>>> std::map<std::string, std::string>& result)
>>>>> {
>>>>> std::cout << "str addr = " << (void*)&str << std::endl;
>>>>> std::cout << "str len " << str.size() << std::endl;
>>>>> std::cout << "str chars = '" << str << "'" << std::endl;
>>>>> std::string::size_type mark_pos = str.find_first_of("?");
>>>>> std::cout << "result of find_first_of is " << mark_pos << std::endl;
>>>>> ... rest of function as before ...
>>>>>
>>>>> So I'm just trying to establish that we're really getting a reference to
>>>>> the same string we thing we were passing, and also whether any access to
>>>>> str (including the length) is problematic, or just accessing the
>>>>> characters.
>>>>>
>>>>>
>>>>> Now, I have one other hypothesis in the back of my mind. You said you
>>>>> were using VS2019. I know that people have been using 2015 and 2017, but
>>>>> I'm wondering if 2019 is the issue here. In particular, is there any
>>>>> chance that VS2019 has changed the representation of std::string (akin to
>>>>> how gcc changed its std::string representation in the ~gcc5 time frame)?
>>>>> And perhaps is it possible that OIIO's dll itself was compiled with one
>>>>> string representation but your program (separate compilation unit) used
>>>>> an incompatible one, so that you are passing what you think is a
>>>>> reference to a std::string but the OIIO code it's calling has a different
>>>>> idea of the internal layout of a std::string?
>>>>>
>>>>> Or is there any other way that the caller and callee (which are in
>>>>> different compilation units and different dlls) might have a different
>>>>> idea of what a std::string means?
>>>>>
>>>>> Ring any bells for anyone?
>>>>>
>>>>>
>>>>>> On Apr 24, 2019, at 1:22 AM, Mathieu Prevot <[email protected]
>>>>>> <mailto:[email protected]>> wrote:
>>>>>>
>>>>>> Yes, there might be something wrong in my locales, `str` could not be
>>>>>> read ( "error reading characters of string" , in my previous post) and
>>>>>> `filename` was undefined.
>>>>>> However, that's not necessarily the problem, the memory is allocated and
>>>>>> I have the same size as in debug (79 characters).
>>>>>> Before ImageInput::open, I print filename to stdout, and I see a correct
>>>>>> result.
>>>>>>
>>>>>> cout << "reading (float) file: " << filename;
>>>>>> auto in = ImageInput::open(filename);
>>>>>>
>>>>>> The right way to be able to read filename is to make a local copy; also
>>>>>> I make certain that I got the correct type (string), even though string
>>>>>> has a default constructor from const char.
>>>>>>
>>>>>> cout << "reading (float) file: " << filename;
>>>>>> string filename2 = filename;
>>>>>> auto in = ImageInput::open(filename2);
>>>>>>
>>>>>> It might be related to the character set, but I don't think since it did
>>>>>> not change from debug to release.
>>>>>> https://stackoverflow.com/questions/9349342/about-the-character-set-option-in-visual-studio
>>>>>>
>>>>>> <https://stackoverflow.com/questions/9349342/about-the-character-set-option-in-visual-studio>
>>>>>>
>>>>>>
>>>>>> In order to acertain this, I did set the character set to "not set" and
>>>>>> tried also "unicode", but I stil got the same memory error.
>>>>>> Here the compile command with "not set" ( /D "_UNICODE" /D "UNICODE"
>>>>>> are removed):
>>>>>>
>>>>>> /permissive- /Yu"pch.h" /GS /GL /W3 /Gy /Zc:wchar_t
>>>>>> /I"c:\lib\tiff\include" /I"c:\lib\openexr\include"
>>>>>> /I"c:\lib\oiio\include" /Zi /Gm- /O2 /sdl /Fd"x64\Release\vc142.pdb"
>>>>>> /Zc:inline /fp:precise /D "NDEBUG" /D "_CONSOLE" /errorReport:prompt
>>>>>> /WX- /Zc:forScope /Gd /Oi /MD /std:c++17 /FC /Fa"x64\Release\" /EHsc
>>>>>> /nologo /Fo"x64\Release\" /Fp"x64\Release\oiioTest.pch"
>>>>>> /diagnostics:classic
>>>>>>
>>>>>> `auto` was `const char*`, therefore did not change a thing.
>>>>>>
>>>>>> With the new lines you suggested, the memory error happens at the first
>>>>>> str usage, ie., str.size().
>>>>>>
>>>>>> std::cout << "str len " << str.size() << " = '" << str << "'" <<
>>>>>> std::endl; // memory error here
>>>>>> std::string::size_type mark_pos = str.find_first_of("?");
>>>>>> std::cout << "result of find_first_of is " << mark_pos << std::endl;
>>>>>>
>>>>>> I tried the local copy with:
>>>>>>
>>>>>> std::string str2 = str; // memory error here
>>>>>> std::string::size_type mark_pos2 = str2.find_first_of("?");
>>>>>> std::string::size_type mark_pos = str.find_first_of("?");
>>>>>>
>>>>>> The memory error happens at the str2 affectation; str has size 79
>>>>>> (expected), and cannot be read, str2 has size 0, allocated 0.
>>>>>>
>>>>>> Not sure where to go next.
>>>>>> Mathieu
>>>>>>
>>>>>>
>>>>>> Le mer. 24 avr. 2019 à 08:26, Larry Gritz <[email protected]
>>>>>> <mailto:[email protected]>> a écrit :
>>>>>> Do you know what your "locale" is? Anything unusual?
>>>>>>
>>>>>> I'm also wondering about the /D "_UNICODE" /D "UNICODE"
>>>>>> What happens if you don't do that?
>>>>>>
>>>>>> Your line,
>>>>>>> auto path =
>>>>>>> "C:/sensomovie/C200/A011C118_19041345_CANON/A011C118_19041345_CANON_00001926.DPX";
>>>>>>
>>>>>> I wonder if you instead used
>>>>>>
>>>>>> const char* path =
>>>>>> "C:/sensomovie/C200/A011C118_19041345_CANON/A011C118_19041345_CANON_00001926.DPX";
>>>>>>
>>>>>> if that changes anything?
>>>>>>
>>>>>> The other idea I had is in get_rest_arguments (src/libutil/strutil.cpp),
>>>>>> could you instrument it like this just to see what happens:
>>>>>>
>>>>>> bool
>>>>>> Strutil::get_rest_arguments(const std::string& str, std::string& base,
>>>>>> std::map<std::string, std::string>& result)
>>>>>> {
>>>>>> std::cout << "str len " << str.size() << " = '" << str << "'" <<
>>>>>> std::endl;
>>>>>> std::string::size_type mark_pos = str.find_first_of("?");
>>>>>> std::cout << "result of find_first_of is " << mark_pos << std::endl;
>>>>>> ... rest of function as before ...
>>>>>>
>>>>>> and see if there is anything interesting printed immediately prior to
>>>>>> the crash?
>>>>>>
>>>>>>
>>>>>>
>>>>>>> On Apr 23, 2019, at 2:53 PM, Mathieu Prevot <[email protected]
>>>>>>> <mailto:[email protected]>> wrote:
>>>>>>>
>>>>>>> I use a debug oiio, and release project; in that case I managed to get
>>>>>>> a call stack.
>>>>>>>
>>>>>>> `str` in `bool Strutil::get_rest_arguments(const std::string& str,
>>>>>>> std::string& base, std::map<std::string, std::string>& result)`
>>>>>>> has a problem ("error reading characters of string").
>>>>>>>
>>>>>>>
>>>>>>> OpenImageIO.dll!OpenImageIO_v2_1::Strutil::get_rest_arguments(const
>>>>>>> std::basic_string<char,std::char_traits<char>,std::allocator<char> > &
>>>>>>> str, std::basic_string<char,std::char_traits<char>,std::allocator<char>
>>>>>>> > & base,
>>>>>>> std::map<std::basic_string<char,std::char_traits<char>,std::allocator<char>
>>>>>>> >,std::basic_string<char,std::char_traits<char>,std::allocator<char>
>>>>>>> >,std::less<std::basic_string<char,std::char_traits<char>,std::allocator<char>
>>>>>>> >
>>>>>>> >,std::allocator<std::pair<std::basic_string<char,std::char_traits<char>,std::allocator<char>
>>>>>>> > const
>>>>>>> ,std::basic_string<char,std::char_traits<char>,std::allocator<char> > >
>>>>>>> > > & result) Line 270 C++
>>>>>>>
>>>>>>> OpenImageIO.dll!OpenImageIO_v2_1::ImageInput::create(const
>>>>>>> std::basic_string<char,std::char_traits<char>,std::allocator<char> > &
>>>>>>> filename, bool do_open, const OpenImageIO_v2_1::ImageSpec * config,
>>>>>>> OpenImageIO_v2_1::string_view plugin_searchpath) Line 512 C++
>>>>>>>
>>>>>>> OpenImageIO.dll!OpenImageIO_v2_1::ImageInput::open(const
>>>>>>> std::basic_string<char,std::char_traits<char>,std::allocator<char> > &
>>>>>>> filename, const OpenImageIO_v2_1::ImageSpec * config) Line 106 C++
>>>>>>> > oiioTest.exe!DPXio::ReadFloat(char *) Line 31 C++
>>>>>>>
>>>>>>> Here my function:
>>>>>>>
>>>>>>> auto DPXio::ReadFloat(const char* filename) -> SparseArray<float>*
>>>>>>> {
>>>>>>> auto in = ImageInput::open(filename);
>>>>>>> if (!in) return nullptr;
>>>>>>>
>>>>>>> auto spec = in->spec();
>>>>>>> DPXfloat.SetSize(spec);
>>>>>>> in->read_image(TypeDesc::FLOAT, DPXfloat.Values);
>>>>>>> in->close();
>>>>>>>
>>>>>>> return &DPXfloat;
>>>>>>> }
>>>>>>>
>>>>>>> and it is called this way:
>>>>>>>
>>>>>>> auto sut = new DPXio();
>>>>>>> auto path =
>>>>>>> "C:/sensomovie/C200/A011C118_19041345_CANON/A011C118_19041345_CANON_00001926.DPX";
>>>>>>> //auto path =
>>>>>>> "C:/sensomovie/C200/A014C203_190414BL_CANON_16bits/A014C203_190414BL_CANON_00001331.DPX";
>>>>>>>
>>>>>>> std::cout << (FileExist(path) ? "File OK: " : "No such file: ") <<
>>>>>>> path << "." << endl;
>>>>>>>
>>>>>>> auto result = sut->ReadFloat(path);
>>>>>>> if (result == nullptr)
>>>>>>> cout << "null result" << endl;
>>>>>>> else
>>>>>>> {
>>>>>>> cout << "colors: " << result->Colors << endl;
>>>>>>> cout << "width: " << result->Width << endl;
>>>>>>> cout << "height: " << result->Height << endl;
>>>>>>> }
>>>>>>>
>>>>>>> The compilation arguments (I'm using VS2019 enterprise, toolset Visual
>>>>>>> Studio 2019 (v142), but I have the same with v141):
>>>>>>>
>>>>>>> /permissive- /Yu"pch.h" /GS /GL /W3 /Gy /Zc:wchar_t
>>>>>>> /I"c:\lib\tiff\include" /I"c:\lib\openexr\include"
>>>>>>> /I"c:\lib\oiio\include" /Zi /Gm- /O2 /sdl /Fd"x64\Release\vc142.pdb"
>>>>>>> /Zc:inline /fp:precise /D "NDEBUG" /D "_CONSOLE" /D "_UNICODE" /D
>>>>>>> "UNICODE" /errorReport:prompt /WX- /Zc:forScope /Gd /Oi /MD /FC
>>>>>>> /Fa"x64\Release\" /EHsc /nologo /Fo"x64\Release\"
>>>>>>> /Fp"x64\Release\oiioTest.pch" /diagnostics:classic
>>>>>>>
>>>>>>> M
>>>>>>>
>>>>>>>
>>>>>>> Le mar. 23 avr. 2019 à 23:39, till dechent <[email protected]
>>>>>>> <mailto:[email protected]>> a écrit :
>>>>>>> Yes I built version 2.0.6 as a release (x64) and it worked. I also
>>>>>>> tried the DPX you provided and all was good.
>>>>>>>
>>>>>>> Am Di., 23. Apr. 2019 um 21:44 Uhr schrieb Mathieu Prevot
>>>>>>> <[email protected] <mailto:[email protected]>>:
>>>>>>> Please, can those who could open images with
>>>>>>> `ImageInput::open(filename)`
>>>>>>> tell if it was a release or debug build (of their own binary, not
>>>>>>> oiio's) ? If it was a debug, can you test with a release build ?
>>>>>>>
>>>>>>> Many thanks
>>>>>>> M
>>>>>>>
>>>>>>> Le lun. 22 avr. 2019 à 16:35, Mathieu Prevot <[email protected]
>>>>>>> <mailto:[email protected]>> a écrit :
>>>>>>> Tested with boost 1.68 and 1.70, both are OK with oiio debug, and
>>>>>>> opening the DPX file works correctly in that configuration.
>>>>>>> Only when I build and use oiio release, it fails (with both boost
>>>>>>> versions).
>>>>>>>
>>>>>>> I'm not sure where to go to continue the investigation.
>>>>>>>
>>>>>>> For repro, my build script; which needs to be run in the ooio-master
>>>>>>> folder as is. msbuild needs to be in $path.
>>>>>>>
>>>>>>> $target = "Visual Studio 15 2017 Win64"
>>>>>>>
>>>>>>> function configure {
>>>>>>>
>>>>>>> I:\IntelSWTools\compilers_and_libraries_2019.3.203\windows\tbb\bin\tbbvars.bat
>>>>>>> intel64 vs2017
>>>>>>> cmake.exe -G $target -T v141, host=x64 -j16 `
>>>>>>>
>>>>>>> -DCMAKE_PREFIX_PATH="I:/lib/tiff;I:\lib\boost-1.70;I:/lib/zlib;I:/lib/libpng;I:/lib/openexr;I:/lib/libjpegturbo"
>>>>>>> `
>>>>>>>
>>>>>>> -DTBB_ROOT_DIR="I:/IntelSWTools/compilers_and_libraries/windows/tbb" `
>>>>>>> -DCMAKE_INSTALL_PREFIX="I:/lib/oiio-release" `
>>>>>>> -DJPEGTURBO_PATH="i:/lib/libjpegturbo" `
>>>>>>> -DUSE_QT=0 -DOIIO_BUILD_TESTS=1 -DUSE_PYTHON=0 `
>>>>>>> -DPYTHON_EXECUTABLE="I:/intelpython2/python.exe" `
>>>>>>> ..
>>>>>>> }
>>>>>>>
>>>>>>> function build {
>>>>>>> #"build oiio debug"
>>>>>>> #MSBuild.exe OpenImageIO.sln /verbosity:m /m
>>>>>>> "build oiio release"
>>>>>>> MSBuild.exe OpenImageIO.sln /p:Configuration=Release /verbosity:m /m
>>>>>>> }
>>>>>>>
>>>>>>> function install {
>>>>>>> #"install oiio debug"
>>>>>>> #MSBuild.exe INSTALL.vcxproj /verbosity:m /m
>>>>>>> "install oiio release"
>>>>>>> MSBuild.exe INSTALL.vcxproj /p:Configuration=Release /verbosity:m /m
>>>>>>> }
>>>>>>>
>>>>>>> function clean {
>>>>>>> if (test-path build) {
>>>>>>> remove-item -recurse -force build
>>>>>>> }
>>>>>>> New-Item -ItemType Directory build
>>>>>>> }
>>>>>>>
>>>>>>> clean
>>>>>>> Set-Location build
>>>>>>> configure
>>>>>>> build
>>>>>>> install
>>>>>>> Set-Location ..
>>>>>>>
>>>>>>>
>>>>>>> Regards
>>>>>>> M
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> Le sam. 20 avr. 2019 à 19:10, Larry Gritz <[email protected]
>>>>>>> <mailto:[email protected]>> a écrit :
>>>>>>> I'm not sure what else I can do unless I either have a case I can
>>>>>>> reproduce on my end, or a more full stack trace or at least indication
>>>>>>> of what specific line in the OIIO is where the exception is thrown
>>>>>>> (just knowing precisely where the crash happens may be enough do
>>>>>>> diagnose or defensively program around).
>>>>>>>
>>>>>>>
>>>>>>>> On Apr 19, 2019, at 2:11 AM, till dechent <[email protected]
>>>>>>>> <mailto:[email protected]>> wrote:
>>>>>>>>
>>>>>>>> ImageInput::open() works for me with the downloaded DPX on version
>>>>>>>> 2.0.6.
>>>>>>>>
>>>>>>>> Am Do., 18. Apr. 2019 um 18:41 Uhr schrieb Stephen Blair
>>>>>>>> <[email protected] <mailto:[email protected]>>:
>>>>>>>> It doesn't crash on Windows for me, but that's with OpenImageIO-Arnold
>>>>>>>> 2.1.0dev
>>>>>>>>
>>>>>>>> On Thu, Apr 18, 2019 at 1:07 PM Larry Gritz <[email protected]
>>>>>>>> <mailto:[email protected]>> wrote:
>>>>>>>> Hi, thanks. I'm able to open that DPX file on my end (not on Windows),
>>>>>>>> so I don't think it's a corrupt file.
>>>>>>>>
>>>>>>>> Can you build all of OIIO in Debug mode (not Release) and use the
>>>>>>>> debugger to find out what file and line is where the actual crash is
>>>>>>>> occurring? The screenshot you provided only shows where in your unit
>>>>>>>> test it was, so the actual crash could be practically anywhere inside
>>>>>>>> what happens within the open() call.
>>>>>>>>
>>>>>>>> I'm sorry I'm not easily able to help, I don't have access to a
>>>>>>>> Windows machine.
>>>>>>>>
>>>>>>>> Can somebody else out there who uses OIIO on Windows please do us a
>>>>>>>> favor and download this DPX file in the links below, then try anything
>>>>>>>> that forces an open (e.g., 'iinfo -v -stats blah.dpx') and report what
>>>>>>>> happens? Does this crash for everybody? If anyone can reproduce, do
>>>>>>>> you have any ideas or can you get closer to finding what line within
>>>>>>>> the OIIO code is the source of the problem?
>>>>>>>>
>>>>>>>> -- lg
>>>>>>>>
>>>>>>>>
>>>>>>>>> On Apr 18, 2019, at 1:16 AM, Mathieu Prevot <[email protected]
>>>>>>>>> <mailto:[email protected]>> wrote:
>>>>>>>>>
>>>>>>>>> Hello,
>>>>>>>>>
>>>>>>>>> Following the documentation "4.1 Image Input Made Simple";
>>>>>>>>> I'm having an exception at opening a dpx file and tiff file from
>>>>>>>>> simple code:
>>>>>>>>>
>>>>>>>>> auto in = ImageInput::open(filename); // here
>>>>>>>>> if (!in) return;
>>>>>>>>>
>>>>>>>>> Exception thrown at 0x00007FFDBEBDA388 in testhost.exe: Microsoft C++
>>>>>>>>> exception:
>>>>>>>>> Microsoft::VisualStudio::CppUnitTestFramework::CSEException
>>>>>>>>>
>>>>>>>>> More detailed information:
>>>>>>>>> https://1drv.ms/u/s!AlUmbfQiLoTZhFQir--TvMglJ0iT
>>>>>>>>> <https://1drv.ms/u/s!AlUmbfQiLoTZhFQir--TvMglJ0iT>
>>>>>>>>>
>>>>>>>>> Images:
>>>>>>>>> https://1drv.ms/f/s!AlUmbfQiLoTZhFKpXHJcchpi0hBY
>>>>>>>>> <https://1drv.ms/f/s!AlUmbfQiLoTZhFKpXHJcchpi0hBY>
>>>>>>>>>
>>>>>>>>> I'm using the master version of oiio in windows with tiff 4.0.10,
>>>>>>>>> openexr 2.3.0, zlib 1.2.11, libpng 1.6.35, boost 1.70, libjpegturbo
>>>>>>>>> 2.0.3, tbb 2019.3; cmake 3.13.4, VS2017.
>>>>>>>>>
>>>>>>>>> I'm running this in a c++ unit test, (with some c code since data
>>>>>>>>> will be used in an interop context).
>>>>>>>>>
>>>>>>>>> TEST_CLASS(DPXioTests)
>>>>>>>>> {
>>>>>>>>> public:
>>>>>>>>> TEST_METHOD(Instance)
>>>>>>>>> {
>>>>>>>>> auto sut = new DPXio();
>>>>>>>>> Assert::IsNotNull(sut);
>>>>>>>>> }
>>>>>>>>>
>>>>>>>>> TEST_METHOD(ReadDPX)
>>>>>>>>> {
>>>>>>>>> auto sut = new DPXio();
>>>>>>>>> auto path =
>>>>>>>>> "C:/sensomovie/C200/A011C118_19041345_CANON/A011C118_19041345_CANON_00001926.DPX";
>>>>>>>>> if(!FileExist(path))
>>>>>>>>> {
>>>>>>>>> wstringstream s;
>>>>>>>>> s << "No such file: " << path << ".";
>>>>>>>>> Logger::WriteMessage(s.str().c_str());
>>>>>>>>> return;
>>>>>>>>> }
>>>>>>>>> try
>>>>>>>>> {
>>>>>>>>> auto result = sut->Read(path);
>>>>>>>>> Assert::IsNotNull(result);
>>>>>>>>> Assert::IsTrue(result->Colors >= 3);
>>>>>>>>> Assert::IsTrue(result->Height == 2160);
>>>>>>>>> Assert::IsTrue(result->Width == 4096);
>>>>>>>>> }
>>>>>>>>> catch (Exception& e)
>>>>>>>>> {
>>>>>>>>> auto lastErrorID = GetLastError();
>>>>>>>>> if (lastErrorID != 0)
>>>>>>>>> {
>>>>>>>>> LPVOID errorBuffer{};
>>>>>>>>> FormatMessage(FORMAT_MESSAGE_ALLOCATE_BUFFER |
>>>>>>>>> FORMAT_MESSAGE_FROM_SYSTEM | FORMAT_MESSAGE_IGNORE_INSERTS,
>>>>>>>>> nullptr, lastErrorID,
>>>>>>>>> MAKELANGID(LANG_NEUTRAL, SUBLANG_DEFAULT), (LPTSTR)&errorBuffer, 0,
>>>>>>>>> nullptr);
>>>>>>>>> wstringstream s;
>>>>>>>>> s << "Exception: " << e.what() << ". ID: "<<
>>>>>>>>> lastErrorID << ". Message: " << errorBuffer<< ".";
>>>>>>>>> Logger::WriteMessage(s.str().c_str());
>>>>>>>>> }
>>>>>>>>> else
>>>>>>>>> {
>>>>>>>>> wstringstream s;
>>>>>>>>> s << "Exception: " << e.what();
>>>>>>>>> Logger::WriteMessage(s.str().c_str());
>>>>>>>>> }
>>>>>>>>> }
>>>>>>>>> }
>>>>>>>>> };
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Mathieu
>>>>>>>>> _______________________________________________
>>>>>>>>> Oiio-dev mailing list
>>>>>>>>> [email protected] <mailto:[email protected]>
>>>>>>>>> http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org
>>>>>>>>> <http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org>
>>>>>>>>
>>>>>>>> --
>>>>>>>> Larry Gritz
>>>>>>>> [email protected] <mailto:[email protected]>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> _______________________________________________
>>>>>>>> Oiio-dev mailing list
>>>>>>>> [email protected] <mailto:[email protected]>
>>>>>>>> http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org
>>>>>>>> <http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org>
>>>>>>>> _______________________________________________
>>>>>>>> Oiio-dev mailing list
>>>>>>>> [email protected] <mailto:[email protected]>
>>>>>>>> http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org
>>>>>>>> <http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org>
>>>>>>>> _______________________________________________
>>>>>>>> Oiio-dev mailing list
>>>>>>>> [email protected] <mailto:[email protected]>
>>>>>>>> http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org
>>>>>>>> <http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org>
>>>>>>>
>>>>>>> --
>>>>>>> Larry Gritz
>>>>>>> [email protected] <mailto:[email protected]>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> _______________________________________________
>>>>>>> Oiio-dev mailing list
>>>>>>> [email protected] <mailto:[email protected]>
>>>>>>> http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org
>>>>>>> <http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org>
>>>>>>> _______________________________________________
>>>>>>> Oiio-dev mailing list
>>>>>>> [email protected] <mailto:[email protected]>
>>>>>>> http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org
>>>>>>> <http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org>
>>>>>>> _______________________________________________
>>>>>>> Oiio-dev mailing list
>>>>>>> [email protected] <mailto:[email protected]>
>>>>>>> http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org
>>>>>>> <http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org>
>>>>>>> _______________________________________________
>>>>>>> Oiio-dev mailing list
>>>>>>> [email protected] <mailto:[email protected]>
>>>>>>> http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org
>>>>>>> <http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org>
>>>>>>
>>>>>> --
>>>>>> Larry Gritz
>>>>>> [email protected] <mailto:[email protected]>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> _______________________________________________
>>>>>> Oiio-dev mailing list
>>>>>> [email protected] <mailto:[email protected]>
>>>>>> http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org
>>>>>> <http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org>
>>>>>> _______________________________________________
>>>>>> Oiio-dev mailing list
>>>>>> [email protected] <mailto:[email protected]>
>>>>>> http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org
>>>>>> <http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org>
>>>>>
>>>>> --
>>>>> Larry Gritz
>>>>> [email protected] <mailto:[email protected]>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> Oiio-dev mailing list
>>>>> [email protected] <mailto:[email protected]>
>>>>> http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org
>>>>> <http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org>
>>>>> _______________________________________________
>>>>> Oiio-dev mailing list
>>>>> [email protected] <mailto:[email protected]>
>>>>> http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org
>>>>> <http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org>
>>>>> _______________________________________________
>>>>> Oiio-dev mailing list
>>>>> [email protected] <mailto:[email protected]>
>>>>> http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org
>>>>> <http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org>
>>>>
>>>> --
>>>> Larry Gritz
>>>> [email protected] <mailto:[email protected]>
>>>>
>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> Oiio-dev mailing list
>>>> [email protected] <mailto:[email protected]>
>>>> http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org
>>>> <http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org>
>>>> _______________________________________________
>>>> Oiio-dev mailing list
>>>> [email protected] <mailto:[email protected]>
>>>> http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org
>>>> <http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org>
>>>
>>> --
>>> Larry Gritz
>>> [email protected] <mailto:[email protected]>
>>>
>>>
>>>
>>>
>>> _______________________________________________
>>> Oiio-dev mailing list
>>> [email protected] <mailto:[email protected]>
>>> http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org
>>> <http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org>
>>> _______________________________________________
>>> Oiio-dev mailing list
>>> [email protected] <mailto:[email protected]>
>>> http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org
>>> <http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org>
>>
>> --
>> Larry Gritz
>> [email protected] <mailto:[email protected]>
>>
>>
>>
>>
>> _______________________________________________
>> Oiio-dev mailing list
>> [email protected] <mailto:[email protected]>
>> http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org
>> <http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org>
>> _______________________________________________
>> Oiio-dev mailing list
>> [email protected] <mailto:[email protected]>
>> http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org
>> <http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org>
>
> --
> Larry Gritz
> [email protected] <mailto:[email protected]>
>
>
>
>
> _______________________________________________
> Oiio-dev mailing list
> [email protected] <mailto:[email protected]>
> http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org
> <http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org>
> _______________________________________________
> Oiio-dev mailing list
> [email protected]
> http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org
--
Larry Gritz
[email protected]
_______________________________________________
Oiio-dev mailing list
[email protected]
http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org
