Hi Michel, We've had similar issues with Blender, and I don't have a good solution for it either. There's a lot of confusing information about this online, my understanding is that to avoid issues you must:
* Ensure all the compiler flags match for the application and all libraries. * Build with /MD instead of /MT when using a DLL. Otherwise the DLL and main application will not use the same heap. /MT does work ok with a static OIIO library. It would be nice if the OIIO (and OSL) API would not use these STL data structures, but this of course involves major API compatibility breakage. So I'm not sure how practical this is. Brecht. On Mon, Apr 8, 2013 at 4:51 PM, Michel Lerenard <[email protected]> wrote: > Hi everybody, > > we've been struggling for a few days hunting a weird bug in > ImageInput::create, and the search raised one major concern about the use of > std::string in the API. > I don't know if the issue has been discussed before (in a sense, I hope > not). > > We've had a crash when trying to open a specific JPEG file. To understand > its cause we built OIIO in debug, to find that the crash occured in the > geterror() function. Apparently it crashed in the destruction of the > std::string that is used in ImageInput::create because it's been > overwritten. > Recompiling with more debug flags we found that strangely the string is > already in a bad state before opening the file: we crashed in the boost > function that extracts the extension of the file. (called from the line > "std::string format = Filesystem::extension (filename)" in > ImageInput::create). > Which is quite weird because it does not relate very well with the crash we > had at the beginning, which was linked to the data in the file. And it now > crashes on every single file we try to open. > > Trying to dig deeper we hit a bunch of issues, mainly related to std::string > and the way it's implemented. > > Is there a reason for using "std::string" instead of a simple "char*" (even > const) in all interface functions ? As far as we're concerned, it's heavy > and raises many compatibility issues especially under windows ( libraries > versions, debug/non debug MT option, etc...). So far we have failed to build > a full debug version of an application using OIIO that does not crash at > startup. Either we can't debug because libraries are in release, either we > crash in mainCRTStartup. > > Our debug session uses the trunk of OIIO and boost 1.44 version. > > We used boost 1.44 because of this bug > https://svn.boost.org/trac/boost/ticket/6320, which seems to have appeared > in 1.48 and was fixed only on boost trunk at this time. At first we used the > 1.49 version then tried the 1.53 and finally the 1.44. Going back to the > 1.44 did change things a bit: with OIIO in release with debug info, no > crash. But OIIO won't load any image. > > ------------------------------ > Michel > Isotropix SAS > > _______________________________________________ > 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
