We actually do link a static copy of OpenEXR into mental ray. Initially, we had problems like symbol conflicts as flags like RTLD_DEEPBIND were not used systematically by applications integrating mental ray. So we put OpenEXR into a different namespace(s). This was actually easy, adding –Dimg=MI_Imf …. to the compiler command line worked. You guys did a great job of adding namespace aliasing support on OpenEXR 2.0 itself, which made the compiler command line hack unnecessary. Juri From: address@hidden [mailto:address@hidden On Behalf Of Peter Hillman
Sent: 06 November, 2013 22:04
To: Christopher Horvath
Cc: OpenEXR Devel List
Subject: Re: [Openexr-devel] Memory leaks in 2.01 It should work most of the time. I was more concerned about edge cases causing unpredictable crashes depending on link flags, dlopen flags and the like, and the implications of introducing the change so that some versions of OpenEXR uninitialize and others do not. On 07/11/13 09:48, Christopher Horvath wrote: If both plugins are statically linked, they'll each have their own copy of any global variables, with their own addresses. Does that fix this, in any way? On Wed, Nov 6, 2013 at 12:44 PM, Peter Hillman <address@hidden> wrote: Would this still be safe if one or both plugins were statically linked against OpenEXR? On 07/11/13 09:41, Halfdan Ingvarsson wrote: The call to uninitialize would be done inside of OpenEXR, and not by any calling plugin. Therefore would only be called once IlmImf.so unloads, which would only happen when all users are done with it.
Basically, this function should both be internal to OpenEXR and OpenEXR alone should be responsible.
This also alleviates a potential race-condition with using a local static Mutex in staticInitialize -- which, prior to C++11 is not guaranteed to be thread-safe -- since DSO load sequences are guaranteed to be single-threaded (although another fix is to move the Mutex to file scope).
Hope this clears it up.
- ½
On 13-11-06 03:25 PM, Peter Hillman wrote: Calling Uninitialize automatically seems dangerous. What happens if a package loads two plugins, both of which are dependent on OpenEXR? If only one is unloaded, there's a danger it would unitialize the attributes for the other, causing a segfault when it tries to parse a header. Alternatively, if both are unloaded, the second might try to free memory already freed by the first.
It seems safer only to call this function manually, and only in a build intended for leak analysis, since the memory returned is insignificant.
_______________________________________________
Openexr-devel mailing list
address@hidden
https://lists.nongnu.org/mailman/listinfo/openexr-devel
--
I think this situation absolutely requires that a really futile and stupid gesture be done on somebody's part. And we're just the guys to do it.
|