From ef160ec07297252524ccab6949e17834c8b5aafc Mon Sep 17 00:00:00 2001 From: Karl Wette Date: Thu, 9 May 2013 14:35:41 +0200 Subject: [PATCH] Octave: remove allocation of new octave_value in SWIG_Octave_SetGlobalValue() - this introduces a memory leak, which becomes significant for large modules (many global variables) and many module re-loadings (e.g. during a long-running script) - the original motivation was to prevent double-frees on exit, but this problem appears to have been fixed by the _Exit() hack in later commits, and in any case is an issue only for Octave ~3.2, so it should be safe to remove; tested by running Octave examples/test suite with Debian 3.2.4 and built-from-source 3.2.4, 3.4.3, and 3.6.3 --- Lib/octave/octrun.swg | 11 +---------- 1 file changed, 1 insertion(+), 10 deletions(-) diff --git a/Lib/octave/octrun.swg b/Lib/octave/octrun.swg index dfb4a7702..8fdb12086 100644 --- a/Lib/octave/octrun.swg +++ b/Lib/octave/octrun.swg @@ -1289,16 +1289,7 @@ SWIGRUNTIMEINLINE octave_value SWIG_Octave_GetGlobalValue(std::string name) { } SWIGRUNTIME void SWIG_Octave_SetGlobalValue(std::string name, const octave_value& value) { - // It is critical that a newly-allocated octave_value is passed to set_global_value(), - // since it and the Octave symbol table take references to the values assigned to it. - // If we were to pass a reference to 'value' to set_global_value(), then the Octave - // symbol table would hold a reference to a variable owned by the SWIG .oct module. - // Both will think that they own the reference (since the .oct module is dynamically - // loaded, it appears to have its own C++ runtime), and so they will both try to - // de-allocate the octave_value on exit, resulting in a double-free or seg-fault. - // This is prevented by giving Octave its own heap-allocated copy of 'value'. - octave_value *pov = new octave_value(value); - set_global_value(name, *pov); + set_global_value(name, value); } SWIGRUNTIME void SWIG_Octave_LinkGlobalValue(std::string name) {