Memory leaks related to Sli

[akorgor]

Valgrind detects several memory leaks related to Sli:

38 bytes in 2 blocks are definitely lost in loss record 451 of 1,030
   at 0x4846FA3: operator new(unsigned long) (in /usr/libexec/valgrind/vgpreload_memcheck-amd64-linux.so)
   by 0x57A3A0FB: void std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >::_M_construct<char*>(char*, char*, std::forward_iterator_tag) [clone .isra.0] (in nest/builds/debug_memory_full_fix/lib/python3.13/site-packages/nest/pynestkernel.so)
   by 0x57A73DBA: AggregateDatum<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >, &SLIInterpreter::Stringtype>::clone() const (in nest/builds/debug_memory_full_fix/lib/python3.13/site-packages/nest/pynestkernel.so)
   by 0x57F4512D: Parser::operator()(Token&) (in nest/builds/debug_memory_full_fix/lib/nest/libsli.so.3.8.0-post0.dev0)
   by 0x57F77B5D: IparseFunction::execute(SLIInterpreter*) const (in nest/builds/debug_memory_full_fix/lib/nest/libsli.so.3.8.0-post0.dev0)
   by 0x57F3E831: SLIInterpreter::execute_(unsigned long) (in nest/builds/debug_memory_full_fix/lib/nest/libsli.so.3.8.0-post0.dev0)
   by 0x57F3E905: SLIInterpreter::startup() (in nest/builds/debug_memory_full_fix/lib/nest/libsli.so.3.8.0-post0.dev0)
   by 0x57A58617: __pyx_pw_12pynestkernel_10NESTEngine_7init(_object*, _object* const*, long, _object*) (in nest/builds/debug_memory_full_fix/lib/python3.13/site-packages/nest/pynestkernel.so)
   by 0x2BF3DD: UnknownInlinedFun (pycore_call.h:168)
   by 0x2BF3DD: PyObject_Vectorcall (call.c:327)
   by 0x1A6937: _PyEval_EvalFrameDefault.cold (generated_cases.c.h:813)
   by 0x379260: PyEval_EvalCode (ceval.c:601)
   by 0x394F78: UnknownInlinedFun (bltinmodule.c:1145)
   by 0x394F78: builtin_exec (bltinmodule.c.h:556)

1,123 bytes in 33 blocks are definitely lost in loss record 836 of 1,030
   at 0x4846FA3: operator new(unsigned long) (in /usr/libexec/valgrind/vgpreload_memcheck-amd64-linux.so)
   by 0x57A3A0FB: void std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >::_M_construct<char*>(char*, char*, std::forward_iterator_tag) [clone .isra.0] (in nest/builds/debug_memory_full_fix/lib/python3.13/site-packages/nest/pynestkernel.so)
   by 0x57A73DBA: AggregateDatum<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >, &SLIInterpreter::Stringtype>::clone() const (in nest/builds/debug_memory_full_fix/lib/python3.13/site-packages/nest/pynestkernel.so)
   by 0x57FAF58F: TokenArrayObj::TokenArrayObj(TokenArrayObj const&) (in nest/builds/debug_memory_full_fix/lib/nest/libsli.so.3.8.0-post0.dev0)
   by 0x57F80348: Put_lpFunction::execute(SLIInterpreter*) const (in nest/builds/debug_memory_full_fix/lib/nest/libsli.so.3.8.0-post0.dev0)
   by 0x57F3E831: SLIInterpreter::execute_(unsigned long) (in nest/builds/debug_memory_full_fix/lib/nest/libsli.so.3.8.0-post0.dev0)
   by 0x57F3E905: SLIInterpreter::startup() (in nest/builds/debug_memory_full_fix/lib/nest/libsli.so.3.8.0-post0.dev0)
   by 0x57A58617: __pyx_pw_12pynestkernel_10NESTEngine_7init(_object*, _object* const*, long, _object*) (in nest/builds/debug_memory_full_fix/lib/python3.13/site-packages/nest/pynestkernel.so)
   by 0x2BF3DD: UnknownInlinedFun (pycore_call.h:168)
   by 0x2BF3DD: PyObject_Vectorcall (call.c:327)
   by 0x1A6937: _PyEval_EvalFrameDefault.cold (generated_cases.c.h:813)
   by 0x379260: PyEval_EvalCode (ceval.c:601)
   by 0x394F78: UnknownInlinedFun (bltinmodule.c:1145)
   by 0x394F78: builtin_exec (bltinmodule.c.h:556)

18,840 (1,200 direct, 17,640 indirect) bytes in 30 blocks are definitely lost in loss record 1,005 of 1,030
   at 0x4846FA3: operator new(unsigned long) (in /usr/libexec/valgrind/vgpreload_memcheck-amd64-linux.so)
   by 0x57FAB129: TrieFunction::execute(SLIInterpreter*) const (in nest/builds/debug_memory_full_fix/lib/nest/libsli.so.3.8.0-post0.dev0)
   by 0x57F3E831: SLIInterpreter::execute_(unsigned long) (in nest/builds/debug_memory_full_fix/lib/nest/libsli.so.3.8.0-post0.dev0)
   by 0x57F3E905: SLIInterpreter::startup() (in nest/builds/debug_memory_full_fix/lib/nest/libsli.so.3.8.0-post0.dev0)
   by 0x57A58617: __pyx_pw_12pynestkernel_10NESTEngine_7init(_object*, _object* const*, long, _object*) (in nest/builds/debug_memory_full_fix/lib/python3.13/site-packages/nest/pynestkernel.so)
   by 0x2BF3DD: UnknownInlinedFun (pycore_call.h:168)
   by 0x2BF3DD: PyObject_Vectorcall (call.c:327)
   by 0x1A6937: _PyEval_EvalFrameDefault.cold (generated_cases.c.h:813)
   by 0x379260: PyEval_EvalCode (ceval.c:601)
   by 0x394F78: UnknownInlinedFun (bltinmodule.c:1145)
   by 0x394F78: builtin_exec (bltinmodule.c.h:556)
   by 0x2DB1A0: cfunction_vectorcall_FASTCALL_KEYWORDS (methodobject.c:441)
   by 0x1A651B: UnknownInlinedFun (call.c:373)
   by 0x1A651B: UnknownInlinedFun (call.c:381)
   by 0x1A651B: _PyEval_EvalFrameDefault.cold (generated_cases.c.h:1355)
   by 0x2E19C3: UnknownInlinedFun (pycore_call.h:168)
   by 0x2E19C3: object_vacall (call.c:819)

55,808 (1,880 direct, 53,928 indirect) bytes in 47 blocks are definitely lost in loss record 1,020 of 1,030
   at 0x4846FA3: operator new(unsigned long) (in /usr/libexec/valgrind/vgpreload_memcheck-amd64-linux.so)
   by 0x57F80339: Put_lpFunction::execute(SLIInterpreter*) const (in nest/builds/debug_memory_full_fix/lib/nest/libsli.so.3.8.0-post0.dev0)
   by 0x57F3E831: SLIInterpreter::execute_(unsigned long) (in nest/builds/debug_memory_full_fix/lib/nest/libsli.so.3.8.0-post0.dev0)
   by 0x57F3E905: SLIInterpreter::startup() (in nest/builds/debug_memory_full_fix/lib/nest/libsli.so.3.8.0-post0.dev0)
   by 0x57A58617: __pyx_pw_12pynestkernel_10NESTEngine_7init(_object*, _object* const*, long, _object*) (in nest/builds/debug_memory_full_fix/lib/python3.13/site-packages/nest/pynestkernel.so)
   by 0x2BF3DD: UnknownInlinedFun (pycore_call.h:168)
   by 0x2BF3DD: PyObject_Vectorcall (call.c:327)
   by 0x1A6937: _PyEval_EvalFrameDefault.cold (generated_cases.c.h:813)
   by 0x379260: PyEval_EvalCode (ceval.c:601)
   by 0x394F78: UnknownInlinedFun (bltinmodule.c:1145)
   by 0x394F78: builtin_exec (bltinmodule.c.h:556)
   by 0x2DB1A0: cfunction_vectorcall_FASTCALL_KEYWORDS (methodobject.c:441)
   by 0x1A651B: UnknownInlinedFun (call.c:373)
   by 0x1A651B: UnknownInlinedFun (call.c:381)
   by 0x1A651B: _PyEval_EvalFrameDefault.cold (generated_cases.c.h:1355)
   by 0x2E19C3: UnknownInlinedFun (pycore_call.h:168)
   by 0x2E19C3: object_vacall (call.c:819)

100,840 (3,840 direct, 97,000 indirect) bytes in 96 blocks are definitely lost in loss record 1,023 of 1,030
   at 0x4846FA3: operator new(unsigned long) (in /usr/libexec/valgrind/vgpreload_memcheck-amd64-linux.so)
   by 0x57F44EED: Parser::operator()(Token&) (in nest/builds/debug_memory_full_fix/lib/nest/libsli.so.3.8.0-post0.dev0)
   by 0x57F77B5D: IparseFunction::execute(SLIInterpreter*) const (in nest/builds/debug_memory_full_fix/lib/nest/libsli.so.3.8.0-post0.dev0)
   by 0x57F3E831: SLIInterpreter::execute_(unsigned long) (in nest/builds/debug_memory_full_fix/lib/nest/libsli.so.3.8.0-post0.dev0)
   by 0x57F3E905: SLIInterpreter::startup() (in nest/builds/debug_memory_full_fix/lib/nest/libsli.so.3.8.0-post0.dev0)
   by 0x57A58617: __pyx_pw_12pynestkernel_10NESTEngine_7init(_object*, _object* const*, long, _object*) (in nest/builds/debug_memory_full_fix/lib/python3.13/site-packages/nest/pynestkernel.so)
   by 0x2BF3DD: UnknownInlinedFun (pycore_call.h:168)
   by 0x2BF3DD: PyObject_Vectorcall (call.c:327)
   by 0x1A6937: _PyEval_EvalFrameDefault.cold (generated_cases.c.h:813)
   by 0x379260: PyEval_EvalCode (ceval.c:601)
   by 0x394F78: UnknownInlinedFun (bltinmodule.c:1145)
   by 0x394F78: builtin_exec (bltinmodule.c.h:556)
   by 0x2DB1A0: cfunction_vectorcall_FASTCALL_KEYWORDS (methodobject.c:441)
   by 0x1A651B: UnknownInlinedFun (call.c:373)
   by 0x1A651B: UnknownInlinedFun (call.c:381)
   by 0x1A651B: _PyEval_EvalFrameDefault.cold (generated_cases.c.h:1355)

[gtrensch]

As these reported memory leaks are not causing any further problems and we are planning to remove the SLI layer from NEST anyway, we will not investigate this further and close this issue.

[heplesser]

@gtrensch In general, I agree with you, but with respect to #3217 I still want to look at these SLI issues. I thus reopen.