To be fair, this will happen any time you have a mismatch in "malloc/free" (you can achieve the same thing on OS X by say loading tcmalloc and calling free on the result of asprintf). An easy way to tickle that is to dlopen things with modes other than RTLD_GLOBAL. Windows people just often link their own C runtimes into every DLL. They call it hell for a reason ;).
On Wed, Mar 25, 2015 at 11:19 AM, Larry Gritz <[email protected]> wrote: > Let me know. It's just a guess at what might be the problem, but it does > seem suspiciously like something that would crop up in the context of a DLL > plugin on Windows. > > > > On Mar 25, 2015, at 11:08 AM, haggi krey <[email protected]> wrote: > > > Great, I'll try it as soon as possible. > > > > haggi > > > > Am 25.03.2015 um 07:50 schrieb Larry Gritz: > >> Haggi, try this: https://github.com/OpenImageIO/oiio/pull/1100 > >> > >> This is against master, but it should be straighforward to apply the > same patch to RB-1.5. > >> > >> See if that clears things up (of course, modify your code to use > destroy() rather than call delete directly). > >> > >> -- lg > >> > >> > >> On Mar 24, 2015, at 11:22 PM, Larry Gritz <[email protected]> wrote: > >> > >>> I have an icky suspicion... I understand that in Windows, it's > dangerous to have memory allocated in one DLL but freed in another. So I'm > worried about that call to create (allocate in the OIIO DLL) and subsequent > delete in the Maya DLL. > >>> > >>> For ImageCache and TextureSystem, we have destroy() functions to go > along with create(), to ensure that the deletions happen in the right DLL's > memory arena. I don't see those for ImageInput/ImageOutput, but now I'm > thinking maybe they are needed. > >>> > >>> I'll prepare a patch for you to try, to see if this addresses the > problem. Stay tuned. > >>> > >>> > >>> On Mar 24, 2015, at 1:38 PM, haggi krey <[email protected]> wrote: > >>> > >>>> Hi, > >>>> > >>>> I have a problem using OpenImageIO for writing exr files if I use it > in a maya plugin on Windows. > >>>> I used it to write the final results of my mayaToCorona renderer > plugin what works fine unless I try to unload the plugin. > >>>> Then maya freezes completly. > >>>> > >>>> Today I tried to use it to write a Arnold exr driver which enables > the writing of AOV with mixed bit depths what Arnold does not yet support. > >>>> Here an output driver is loaded during rendering and unloaded after > rendering and exactly the same happens. I use it with mtoa on windows. > >>>> As soon as Arnold tried to unload the driver after a rendering is > done, maya freezes. > >>>> > >>>> Maybe anyone has some experience with this or has any idea what is > happening here. I have tried the following: > >>>> > >>>> > >>>> OIIO::ImageOutput *out = OIIO::ImageOutput::create(filename); > >>>> delete out; > >>>> > >>>> The problem only appears if the filename is an exr file. With jpeg or > tiff, everything works fine without any problems. > >>>> So my idea was to check if the problem has something to do with > openExr itself so I tried to write a simple file with Imf tools: > >>>> > >>>> void writeExrTest() > >>>> { > >>>> int width = 512; > >>>> int height = 512; > >>>> const char *fileName = "c:/daten/testimage.exr"; > >>>> Rgba *pixels = new Rgba[512*512]; > >>>> RgbaOutputFile file(fileName, width, height, WRITE_RGBA); > >>>> file.setFrameBuffer (pixels, 1, width); > >>>> file.writePixels (height); > >>>> } > >>>> > >>>> And this worked fine - no blocking. > >>>> I use openExr 2.2 together with OIIO 1.5. Compiled with Visual c++ 11 > on Windows7. > >>>> Tomorrow I'll try to export an ass file and check if the same happens > with the standalone. > >>>> And I did not try it in release mode yet. I'll check it tomorrow. > >>>> > >>>> I'd really appreciate any ideas. Of course I can implement it > completly without OpenImageIO but I prefer to use it because it makes life > easier. > >>>> > >>>> haggi > >>>> > >>>> _______________________________________________ > >>>> 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 > >> -- > >> 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
