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();
{
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:
address@hidden
[mailto:address@hidden]
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:
address@hidden
[mailto:address@hidden]
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
address@hidden
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
|