Re: 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 <[email protected] >
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

[email protected]

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.

_______________________________________________
Openexr-devel mailing list
[email protected]
https://lists.nongnu.org/mailman/listinfo/openexr-devel