Thanks for testing my patch. :-)
It's obvious, but it should be said: This patch isn't thread-safe at all
(with and without Juris fix). Any other thread can acquire the typemap
after the bracket '}'.
Michael
Am 05.11.2013 18:18, schrieb Juri Abramov:
*Thanks a lot Michael,*
**
*Your patch work, with one modification:*
**
void
Attribute::clearAttributeRegistration()
{
LockedTypeMap& tMap= typeMap();
{
Locklock(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
----------
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
