Re: DLL memory leaks
- Posted by jimcbrown (admin) Feb 05, 2014
- 1415 views
Hallo
I tried to follow this thread.
I tried to understand what's going on.
But i didn't get it.
i found the following in the referenced links...
It's a quote from jimcbrown.
I'm not so sure that this is the full story now. I tried cutting out std/dll.e entirely here, using only the operating system library (plus a small helper c lib to deal with the E_SEQUENCE transition), and on startup it uses 14MB but then only uses 2MB more (16MB total) for 10k runs. However, for 90k runs (which takes 27 seconds), it uses 75MB total. http://openeuphoria.org/pastey/155.wc I even tried cutting out the calls to the helper lib, in case repeated c_func() calls or the creation of new sequences was the culprit, but I still saw 75MB after 90k runs. I guess even using dlclose() doesn't do the job.
Why should a program that uses a dll 90000 times in 27seconds release this dll always after using it?
Maybe I'am a stupid but, really, i do not understand this.
(Please have patience, I'am not a programing expert)
Please help.
Andreas
You are not stupid. Using a shared library 90k times in 27 seconds and releasing it always after using it, that's what is stupid. ;)
That was an example test case for the worst case scenario, in order to demonstrate the bug. While it'd be unusual to unload and reload the same shared object so many times, or within shuch a short time frame, there are many applications out there that are written in a modular fashion, with functionality implemented in helper shared libraries. It makes sense that the application would only load the librares on demand, on an as-needed basis, and perhaps it should unload them when it realises that it wouldn't need that particular helper library again (to use resources such as memory more efficently). But this bug (that a library won't always unload itself cleanly) affects the more common use case scenarios as well.
