How can I have together (in the same folder) debug and release binaires, like: OpenImageIO.dll OpenImageIOd.dll ?
M Le jeu. 25 avr. 2019 à 21:13, Mathieu Prevot <[email protected]> a écrit : > I'm not certain, and this seems likely to smells there. > > I know for certain that oiioTest debug + oiio debug works with full DCI4k > 10bits image, > but fails with a cropped sample I shared. But I have a release OpenEXR. > > I guess I should check the whole tree of dependencies. > > M > > Le jeu. 25 avr. 2019 à 21:02, Thiago Ize <[email protected]> a écrit : > >> 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 >> >
_______________________________________________ Oiio-dev mailing list [email protected] http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org
