|
Ideally the two calls should eventually
be wrapped inside of a DllMain (Windows), or marked with
__attribute__((constructor/destructor)) (Linux/OSX), making it all
nice, tidy and automatic.
- ½
On 13-11-05 05:31 AM, Michael Reinhardt wrote:
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
_______________________________________________
Openexr-devel mailing list
address@hidden
https://lists.nongnu.org/mailman/listinfo/openexr-devel
|