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
>
> <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]
> 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
