Re: Memory leaks in 2.01
Halfdan Ingvarsson <[email protected]>
| Newsgroups | gmane.comp.video.openexr.devel |
|---|---|
| Message-ID | <[email protected]> |
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:*[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 > > > > _______________________________________________ > Openexr-devel mailing list > [email protected] > https://lists.nongnu.org/mailman/listinfo/openexr-devel _______________________________________________ Openexr-devel mailing list [email protected] https://lists.nongnu.org/mailman/listinfo/openexr-devel