Are you sure all the libraries and executables are built with the same settings? With visual studio (at least the older versions I used) mixing for instance debug and release builds can result in different versions of core libraries being used and you'll get crashes.
On Thu, Apr 25, 2019 at 12:57 PM Larry Gritz <[email protected]> wrote: > 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]> 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]> >> 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]> 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]> >>> 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]> 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]> >>>> 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]> 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]> >>>>> 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 >>>>> >>>>> 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]> 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 >>>>>> >>>>>> 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]>: >>>>>> >>>>>>> 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]> 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 >>>>>>> >>>>>>> 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]> 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]> 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]> >>>>>>>> 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]>: >>>>>>>>> >>>>>>>>>> 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]> 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]> 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]> 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]>: >>>>>>>>>>>> >>>>>>>>>>>>> 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]> >>>>>>>>>>>>> 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]> 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 >>>>>>>>>>>>>> >>>>>>>>>>>>>> Images: >>>>>>>>>>>>>> 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] >>>>>>>>>>>>>> >>>>>>>>>>>>>> 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 >>>>>>>>>>>>>> >>>>>>>>>>>>> _______________________________________________ >>>>>>>>>>>>> Oiio-dev mailing list >>>>>>>>>>>>> [email protected] >>>>>>>>>>>>> >>>>>>>>>>>>> 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 >>>>>>>>>>>> >>>>>>>>>>> _______________________________________________ >>>>>>>>>> Oiio-dev mailing list >>>>>>>>>> [email protected] >>>>>>>>>> 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 >>>>>>>>> >>>>>>>> _______________________________________________ >>>>>>>> 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 >>>>>>>> >>>>>>> _______________________________________________ >>>>>>> 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 >>>>>>> >>>>>> _______________________________________________ >>>>>> Oiio-dev mailing list >>>>>> [email protected] >>>>>> 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 >>>>> >>>> _______________________________________________ >>>> 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 >>>> >>> _______________________________________________ >>> 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 >>> >> _______________________________________________ >> 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 >> > _______________________________________________ > 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 >
_______________________________________________ Oiio-dev mailing list [email protected] http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org
