A little while ago I mentioned in #znc about a memory leak problem I was experiencing. What was happening was that I'd start up ZNC (1.6), and about two weeks later, I'd be at my servers comfortable memory limit (gone up from 50% -> 93%) after steadily rising during its running.
I upgraded from ZNC 1.4 on the same server, which didn't have this issue at all. The only difference between the two version is that I "upgraded" from znc-push's C branch to the actively developed Python branch. This meant I needed to also compile ZNC 1.6 with modpython (which I didn't have previously). This, on one hand, makes me suspect either modpython or push as the responsible parties. However, doing a /msg *status unloadmod push; /msg *status unloadmod modpython does not reduce memory usage at all.
Having said that, I haven't tried starting ZNC with both of these disabled - only unloading them and reloading them (as two separate tests). Aside from these, the only other modules I use are "core" modules. I can provide a breakdown if need be.
As for memory usage profiling, I've run ZNC under massif for the last few days, and each of the different functions do not grow (significantly) in usage over time, except one. The details of which are listed below:
The text of the largest snapshot, nested, are as follows:
0x593F207: std::string::_Rep::_S_create(unsigned long, unsigned long, std::allocator<char> const&)(in /usr/lib/x86_64-linux-gnu/libstdc++.so.6.0.19)
0x594092F: char* std::string::_S_construct<char const*>(char const*, char const*, std::allocator<char> const&, std::forward_iterator_tag)(in /usr/lib/x86_64-linux-gnu/libstdc++.so.6.0.19)
0x59409EB: std::basic_string<char, std::char_traits<char>, std::allocator<char> >::basic_string(char const*, unsigned long, std::allocator<char> const&)(in /usr/lib/x86_64-linux-gnu/libstdc++.so.6.0.19)
0x8774845: SWIG_AsPtr_std_string(_object*, CString**)(in /usr/local/lib/znc/modpython/_znc_core.so)
0x87F51B5: _wrap_CIRCNetwork_ExpandString (in /usr/local/lib/znc/modpython/_znc_core.so)
0x784A201: PyEval_EvalFrameEx (in /usr/lib/x86_64-linux-gnu/libpython3.4m.so.1.0)
0x7973514: PyEval_EvalCodeEx (in /usr/lib/x86_64-linux-gnu/libpython3.4m.so.1.0)
0x784A56B: PyEval_EvalFrameEx (in /usr/lib/x86_64-linux-gnu/libpython3.4m.so.1.0)
0x784C943: PyEval_EvalFrameEx (in /usr/lib/x86_64-linux-gnu/libpython3.4m.so.1.0)
0x7973B44: ??? (in /usr/lib/x86_64-linux-gnu/libpython3.4m.so.1.0)
0x7888456: PyObject_Call (in /usr/lib/x86_64-linux-gnu/libpython3.4m.so.1.0)
0x78B181B: ??? (in /usr/lib/x86_64-linux-gnu/libpython3.4m.so.1.0)
0x7888456: PyObject_Call (in /usr/lib/x86_64-linux-gnu/libpython3.4m.so.1.0)
0x7868ADF: PyObject_CallMethodObjArgs (in /usr/lib/x86_64-linux-gnu/libpython3.4m.so.1.0)
0x75227FB: CPyModule::OnChanMsg(CNick&, CChan&, CString&)(in /usr/local/lib/znc/modpython.so)
0x4BBADE: CModules::OnChanMsg(CNick&, CChan&, CString&)(in /usr/local/bin/znc)
0x47EDA8: CIRCSock::OnChanMsg(CNick&, CString const&, CString&)(in /usr/local/bin/znc)
0x48F4A1: CIRCSock::ReadLine(CString const&)(in /usr/local/bin/znc)
0x4411DE: Csock::PushBuff(char const*, unsigned long, bool)(in /usr/local/bin/znc)
0x44A50C: CSocketManager::Loop()(in /usr/local/bin/znc)
0x4483BF: CSocketManager::DynamicSelectLoop(unsigned long, unsigned long, long)(in /usr/local/bin/znc)
0x45B56E: CZNC::Loop()(in /usr/local/bin/znc)
0x430369: main (in /usr/local/bin/znc)
This, to me, certainly makes it look more Python-related, but I'd love to help track it down if I can in any way. Keep in mind, not a programmer by any means - just love the project 😄
Just for completeness, the rest of the expanded info is below in the screenshots:
Hey guys,
A little while ago I mentioned in #znc about a memory leak problem I was experiencing. What was happening was that I'd start up ZNC (1.6), and about two weeks later, I'd be at my servers comfortable memory limit (gone up from 50% -> 93%) after steadily rising during its running.
I upgraded from ZNC 1.4 on the same server, which didn't have this issue at all. The only difference between the two version is that I "upgraded" from znc-push's C branch to the actively developed Python branch. This meant I needed to also compile ZNC 1.6 with modpython (which I didn't have previously). This, on one hand, makes me suspect either _modpython_ or _push_ as the responsible parties. However, doing a `/msg *status unloadmod push; /msg *status unloadmod modpython` does not reduce memory usage at all.
Having said that, I haven't tried starting ZNC with both of these disabled - only unloading them and reloading them (as two separate tests). Aside from these, the only other modules I use are "core" modules. I can provide a breakdown if need be.
As for memory usage profiling, I've run ZNC under massif for the last few days, and each of the different functions do not grow (significantly) in usage over time, except one. The details of which are listed below:

The text of the largest snapshot, nested, are as follows:
``` bash
0x593F207: std::string::_Rep::_S_create(unsigned long, unsigned long, std::allocator<char> const&) (in /usr/lib/x86_64-linux-gnu/libstdc++.so.6.0.19)
0x594092F: char* std::string::_S_construct<char const*>(char const*, char const*, std::allocator<char> const&, std::forward_iterator_tag) (in /usr/lib/x86_64-linux-gnu/libstdc++.so.6.0.19)
0x59409EB: std::basic_string<char, std::char_traits<char>, std::allocator<char> >::basic_string(char const*, unsigned long, std::allocator<char> const&) (in /usr/lib/x86_64-linux-gnu/libstdc++.so.6.0.19)
0x8774845: SWIG_AsPtr_std_string(_object*, CString**) (in /usr/local/lib/znc/modpython/_znc_core.so)
0x87F51B5: _wrap_CIRCNetwork_ExpandString (in /usr/local/lib/znc/modpython/_znc_core.so)
0x784A201: PyEval_EvalFrameEx (in /usr/lib/x86_64-linux-gnu/libpython3.4m.so.1.0)
0x7973514: PyEval_EvalCodeEx (in /usr/lib/x86_64-linux-gnu/libpython3.4m.so.1.0)
0x784A56B: PyEval_EvalFrameEx (in /usr/lib/x86_64-linux-gnu/libpython3.4m.so.1.0)
0x784C943: PyEval_EvalFrameEx (in /usr/lib/x86_64-linux-gnu/libpython3.4m.so.1.0)
0x7973B44: ??? (in /usr/lib/x86_64-linux-gnu/libpython3.4m.so.1.0)
0x7888456: PyObject_Call (in /usr/lib/x86_64-linux-gnu/libpython3.4m.so.1.0)
0x78B181B: ??? (in /usr/lib/x86_64-linux-gnu/libpython3.4m.so.1.0)
0x7888456: PyObject_Call (in /usr/lib/x86_64-linux-gnu/libpython3.4m.so.1.0)
0x7868ADF: PyObject_CallMethodObjArgs (in /usr/lib/x86_64-linux-gnu/libpython3.4m.so.1.0)
0x75227FB: CPyModule::OnChanMsg(CNick&, CChan&, CString&) (in /usr/local/lib/znc/modpython.so)
0x4BBADE: CModules::OnChanMsg(CNick&, CChan&, CString&) (in /usr/local/bin/znc)
0x47EDA8: CIRCSock::OnChanMsg(CNick&, CString const&, CString&) (in /usr/local/bin/znc)
0x48F4A1: CIRCSock::ReadLine(CString const&) (in /usr/local/bin/znc)
0x4411DE: Csock::PushBuff(char const*, unsigned long, bool) (in /usr/local/bin/znc)
0x44A50C: CSocketManager::Loop() (in /usr/local/bin/znc)
0x4483BF: CSocketManager::DynamicSelectLoop(unsigned long, unsigned long, long) (in /usr/local/bin/znc)
0x45B56E: CZNC::Loop() (in /usr/local/bin/znc)
0x430369: main (in /usr/local/bin/znc)
```
This, to me, certainly makes it look more Python-related, but I'd love to help track it down if I can in any way. Keep in mind, not a programmer by any means - just love the project :smile:
Just for completeness, the rest of the expanded info is below in the screenshots:


<!-- github-sync-id:98953683 -->
Thanks @stevesbrain for detailed info!
I reproduced it, with the following minimal python module:
``` py
import znc
s = "aaaaaaaaaaaaaa"
for y in range(10):
s += s
class ptest(znc.Module):
def OnLoad(self, args, msg):
while True:
self.GetNetwork().SetRealName(s)
```
<!-- github-comment-id:127743077 -->
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
Hey guys,
A little while ago I mentioned in #znc about a memory leak problem I was experiencing. What was happening was that I'd start up ZNC (1.6), and about two weeks later, I'd be at my servers comfortable memory limit (gone up from 50% -> 93%) after steadily rising during its running.
I upgraded from ZNC 1.4 on the same server, which didn't have this issue at all. The only difference between the two version is that I "upgraded" from znc-push's C branch to the actively developed Python branch. This meant I needed to also compile ZNC 1.6 with modpython (which I didn't have previously). This, on one hand, makes me suspect either modpython or push as the responsible parties. However, doing a
/msg *status unloadmod push; /msg *status unloadmod modpythondoes not reduce memory usage at all.Having said that, I haven't tried starting ZNC with both of these disabled - only unloading them and reloading them (as two separate tests). Aside from these, the only other modules I use are "core" modules. I can provide a breakdown if need be.
As for memory usage profiling, I've run ZNC under massif for the last few days, and each of the different functions do not grow (significantly) in usage over time, except one. The details of which are listed below:
The text of the largest snapshot, nested, are as follows:
This, to me, certainly makes it look more Python-related, but I'd love to help track it down if I can in any way. Keep in mind, not a programmer by any means - just love the project 😄
Just for completeness, the rest of the expanded info is below in the screenshots:
Thanks @stevesbrain for detailed info!
I reproduced it, with the following minimal python module: