Re: Memory leaks in 2.01

Indeed, under Linux there would be issues that are dependent on how the
plug-in is compiled and linked. (Others could speak to issues related
to other operating systems.)

For instance, if a plug-in does link against OpenEXR statically but
does not do anything about limiting where it finds global symbols (like
not using -Wl,-Bsymbolic or other related options) then the
plug-in can end up binding to OpenEXR symbols from elsewhere in the
process.

With namespaces, at least we have a mechanism to make sure
that those additional copies of those symbols are related to a
compatible implementation. But it does mean that there can be
additional unrelated code piggy-backing on static data that might
otherwise be controlled by initialization and clean-up that expects
only one call each.

If we were to add clean-up, we would need to have a corresponding count
of the number explicit requests to initialize.

On 11/07/13 10:04, Peter Hillman wrote:

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