Bug 2455 - Leaking memory when continuously dlopen and dlclose shared objects
Summary: Leaking memory when continuously dlopen and dlclose shared objects
Status: RESOLVED FIXED
Alias: None
Product: uClibc
Classification: Unclassified
Component: Shared Library Support (show other bugs)
Version: 0.9.31
Hardware: PC Linux
: P5 normal
Target Milestone: ---
Assignee: Carmelo Amoroso
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2010-08-27 14:40 UTC by Ronald Wahl
Modified: 2013-02-05 15:01 UTC (History)
1 user (show)

See Also:
Host:
Target:
Build:


Attachments
Proposed fix (679 bytes, patch)
2010-08-27 14:40 UTC, Ronald Wahl
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Ronald Wahl 2010-08-27 14:40:58 UTC
Created attachment 2389 [details]
Proposed fix

I noticed some strange memory leak which grows when continuously dlopen and dlclose shared objects. This happens for example when you use net-snmp with plugins and reconfigure the daemon by sending a SIGHUP signal. In  this case the modules are unloaded (dlclose) and loaded again (dlopen). After debugging a bit I found out that in _atexit.c we allocate a new function slot in the __exit_function_table for each function that should be called on dlclose. That can be quite a lot functions when using C++ in the module. Now after dlclose the entries are marked as free again but are not reused on the next dlopen call which leads to an ever growing __exit_function_table that will be freed only when the main process exits.

My proposed fix is to zap the largest free block at the end and reuse it. See
the attached patch.
Comment 1 Carmelo Amoroso 2011-02-09 11:55:42 UTC
Hi,
there are been reported other mem leak in dlopen and a patch was posted trying to address a different issue.

I've looked at it and it seems to be fine to be applied. Once pushed, I'd ask you to try again to see if the other also helps.

I'll look at your patch also.
Comment 2 Bernhard Reutner-Fischer 2012-04-18 08:59:03 UTC
Carmelo, i think this is fixed in master and the 0.9.33 branch, yes?
Comment 3 Carmelo Amoroso 2012-04-18 13:10:38 UTC
(In reply to comment #2)
> Carmelo, i think this is fixed in master and the 0.9.33 branch, yes?

master and 0.9.33 include another memleak fix, not that one mentioned in comment 1.

I've guilty as I've not had time to review and commit.
Comment 4 Carmelo Amoroso 2013-02-01 15:03:09 UTC
(In reply to comment #3)
> (In reply to comment #2)
> > Carmelo, i think this is fixed in master and the 0.9.33 branch, yes?
> 
> master and 0.9.33 include another memleak fix, not that one mentioned in
> comment 1.
> 
> I've guilty as I've not had time to review and commit.

Hello,
we are etsting this patch as an our customer is raised a similar issue that this patch is solving.

If everything is fine, I'll commit.

Thanks and sorry for a so late reply.

Carmelo
Comment 5 Ronald Wahl 2013-02-01 15:12:00 UTC
Great! Better late than never. ;-)

- ron
Comment 6 Carmelo Amoroso 2013-02-05 15:01:58 UTC
Fix applied in master and 0.9.33.

Thanks a lot,
Carmelo