| Summary: | Leaking memory when continuously dlopen and dlclose shared objects | ||
|---|---|---|---|
| Product: | uClibc | Reporter: | Ronald Wahl <ronald.wahl> |
| Component: | Shared Library Support | Assignee: | Carmelo Amoroso <carmelo.amoroso> |
| Status: | RESOLVED FIXED | ||
| Severity: | normal | CC: | uclibc-cvs |
| Priority: | P5 | ||
| Version: | 0.9.31 | ||
| Target Milestone: | --- | ||
| Hardware: | PC | ||
| OS: | Linux | ||
| Host: | Target: | ||
| Build: | |||
| Attachments: | Proposed fix | ||
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. Carmelo, i think this is fixed in master and the 0.9.33 branch, yes? (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. (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 Great! Better late than never. ;-) - ron Fix applied in master and 0.9.33. Thanks a lot, Carmelo |
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.