Message189227
| Author |
jsafrane |
| Recipients |
amaury.forgeotdarc, benjamin.peterson, dabeaz, jsafrane, pitrou |
| Date |
2013年05月14日.15:28:11 |
| SpamBayes Score |
-1.0 |
| Marked as misclassified |
Yes |
| Message-id |
<51925809.2020104@redhat.com> |
| In-reply-to |
<518B4B4A.5000109@redhat.com> |
| Content |
On 05/09/2013 09:07 AM, Jan Safranek wrote:
>
> Jan Safranek added the comment:
>
> On 05/07/2013 05:32 PM, Antoine Pitrou wrote:
>> Jan, one possibility would be for Pegasus to stop "unloading" Python,
>> it seems.
>
> It is always possibility. Actually, Pegasus "plugin" is just a shared
> object (.so) and the .so is linked with Python. Pegasus calls dlopen()
> and dlclose() on it. After dlclose(), the "plugin" is removed from
> memory. Unfortunately, libpython2.7.so stays loaded, at least
> /proc/XXX/mems says so. If there was a way to unload libpython2.7.so
> from memory too...
libpython2.7.so is not unloaded because python extensions, e.g.
/usr/lib64/python2.7/lib-dynload/_heapq.so depend on it. And _heapq.so
was dlopenened by Python and it was not dlclosed -> glibc does not
unload it.
It seems that Py_Finalize() does not even close opened shared objects.
Isn't it a bug?
Jan |
|