Re: Memory leaks in 2.01

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:*[email protected] 
> [mailto:[email protected]] *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:*[email protected]
>     <mailto:[email protected]>
>     [mailto:[email protected]] *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
>
>         [email protected]  <mailto:[email protected]>
>
>         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
[email protected]
https://lists.nongnu.org/mailman/listinfo/openexr-devel