Thanks a lot Michael,
Your patch work, with one modification:
void
Attribute::clearAttributeRegistration ()
{
LockedTypeMap& tMap = typeMap();
{
Lock lock (tMap.mutex);
tMap.clear ();
}
clearTypeMap();
}
Note the brackets I've added. Your code called clearTypeMap on a locked
typeMapVar, which caused EBUSY assert on deleting the mutex.
Bests,
Juri
From: openexr-devel-bounces+gabramov=nvidia....@nongnu.org
[mailto:openexr-devel-bounces+gabramov=nvidia....@nongnu.org] On Behalf Of
Michael Reinhardt
Sent: 05 November, 2013 11:31
To: OpenEXR Devel List
Subject: Re: [Openexr-devel] Memory leaks in 2.01
Hi,
if it is convenient for you to call a single method upon unloading, my patch
might help you. You have to call "OPENEXR_IMF_NAMESPACE::staticUninitialize();"
(I know, this is not the best name for it.) when you want to unload the
library. It will delete the typemap and kill the memory leak. It works flawless
in my application, but I can't guarantee that it will work in every situation.
;-) What I want to say: This is a quick hack. There might be bugs inside.
Michael
P.s.: I had to adjust the file structure of the IlmImf library, so the file
paths in the patch file won't fit.
Am 04.11.2013 16:17, schrieb Juri Abramov:
Note that if someone builds a plugin around OpenEXR library and unloads it, the
memory leak is there. It is small, and mostly just annoying as one needs to add
exceptions for memory leak hunting tools. It would be great to have some clean
function/method.
Juri
From:
openexr-devel-bounces+gabramov=nvidia....@nongnu.org<mailto:openexr-devel-bounces+gabramov=nvidia....@nongnu.org>
[mailto:openexr-devel-bounces+gabramov=nvidia....@nongnu.org] On Behalf Of
Michael Reinhardt
Sent: 04 November, 2013 15:58
To: OpenEXR Devel List
Subject: Re: [Openexr-devel] Memory leaks in 2.01
Hi Gerhard,
I don't think you encountered a real memory leak. It just looks like one. (I
stumbled upon this "leak" some time ago ;-) ). Upon creating a file - or
something else that can handle Header object - a function named
staticInitialize() (ImfHeader.h) is called. This function registers the basic
attributes (e.g. Double, String, ...). These basic attributes are stored inside
a static variable of the type LockedTypeMap (ImfAttribute.c). Afterwards, they
are not touched again. The registration remains until the process ends. This is
expected behaviour in my opinion. (Initialization is done once.)
Since the container for the basic attributes is a "function static variable",
it will be deleted upon exit of the calling process. (As all remaining memory
allocations will do.)
This memory is allocated once. There is no growing runtime leak. Your memory
leak detector is getting angry, because it checks the memory map too early.
This "lazy static initialization" isn't recognized by the mem checker.
IMHO, there is no way to circumvent this behaviour without having to initialize
the typemap with every creation of an FileObject. And that's not very
performant.
I hope, I could allay your concerns.
Michael
Am 04.11.2013 08:04, schrieb Gerhard Huber:
Hi,
when I just create in InputFile
EXRReadFile exrFile(file);
InputFile inFile(exrFile);
I get some memory leaks. I think the problem are some unreleased Attributes.
The size of the memory leaks is almost 48 Bytes and one with 104 Bytes.
Gerhard
_______________________________________________
Openexr-devel mailing list
Openexr-devel@nongnu.org<mailto:Openexr-devel@nongnu.org>
https://lists.nongnu.org/mailman/listinfo/openexr-devel
----------
visit us at
Medica 2013 / Duesseldorf, Germany /20-23 November / hall 16-D54
________________________________
This email message is for the sole use of the intended recipient(s) and may
contain confidential information. Any unauthorized review, use, disclosure or
distribution is prohibited. If you are not the intended recipient, please
contact the sender by reply email and destroy all copies of the original
message.
________________________________
----------
visit us at
Medica 2013 / Duesseldorf, Germany /20-23 November / hall 16-D54
_______________________________________________
Openexr-devel mailing list
Openexr-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/openexr-devel
