c++, swig and mpatrol

[Andrew Collier]

hello,

i am not sure whether this problem relates to swig, python or my c++ compiler.
+please forgive me if this is inappropriately posted but i am sure that someone
+on this list must have some good ideas. i have also sent i to the swig
users list a couple of times but have not got any response so i am casting
my net a little wider...

i have been struggling with the following problem for a couple of days now.
+specifically, i have a logger class within a larger project. this class
is coded in c++ but this is all wrapped up in a python interface which i
generate with swig. recently i built the project with mpatrol and got some
errors like:

ERROR: [NOTALL]: free: 0x0806E758 has not been allocated

so i trimmed down all the excess stuff until i had the minimum code which still
+produced the errors.

the header file looks like:

-- log.h -----------------------------------------------------------------------

#ifndef _LOG_H
#define _LOG_H

#include <string>

class Logger {
public:
void debug(const std::string msg) {cerr << msg << endl;}
};

extern Logger logger;

#endif

--------------------------------------------------------------------------------

and this is swig'd via the following simple interface file:

-- log.i -----------------------------------------------------------------------

%module log

%{
#include "log.h"
%}

%include std_string.i

%include log.h

%pythoncode %{
logger = _log.cvar.logger
%}

--------------------------------------------------------------------------------

the global instance of the Logger class, logger, is the only thing in the source
+file log.cc.

i build the project with the following:

-- Makefile --------------------------------------------------------------------

%.o: %.cc
g++ -I/usr/local/include/python2.3 -g -O -c $<

_logmodule.so: log.o log_wrap.o
g++ -shared -o $@ $^ -lmpatrol -lbfd

log_wrap.cc log.py: log.i
swig -c++ -python -shadow -o log_wrap.cc $<

--------------------------------------------------------------------------------

now, when i run this snippet of python code:

import log

msg = "xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx xxxxxxxxxxxxxxx"
log.logger.debug(msg)

the mpatrol.log file has:

FREE: free (0x0804BA18) [-|-|-]
0x001280C9 _wrap_Logger_debug+897
0x0017A3C6 PyCFunction_Call+150
0x001543F9 PyObject_Call+45
0x001AF0A2 PyEval_CallObjectWithKeywords+206
0x001A4113 builtin_apply+323
0x0017A3C6 PyCFunction_Call+150
0x001AF1F1 call_function+301
0x001AD864 eval_frame+10576
0x001AE824 PyEval_EvalCodeEx+1848
0x001B0EB9 fast_function+297
0x001AF27A call_function+438
0x001AD864 eval_frame+10576
0x001AE824 PyEval_EvalCodeEx+1848
0x001B0D26 PyEval_EvalCode+50
0x001D1144 run_node+76
0x001D10E7 run_err_node+47
0x001D0DE3 PyRun_FileExFlags+107
0x001CF832 PyRun_SimpleFileExFlags+406
0x001D092F PyRun_AnyFileExFlags+107
0x001D7277 Py_Main+2119
0x08048611 main+33
0x002C717D __libc_start_main+189
0x08048531 _start+33

ERROR: [NOTALL]: free: 0x0804BA18 has not been allocated

which seems to indicate that memory is being free'd without be previously
+allocated. the odd thing is that if i either:

o compile with -O0,
o make the msg string ("xxx....xxx") one character shorter

then the error goes away. this seems very mysterious to me given that it is a
+very simple little module.

if i set MPATROL_OPTIONS="CHECKALL USEDEBUG" then there is a little more
+information:

FREE: free (0x0806F448)
+[_wrap_Logger_debug|/usr/lib/gcc-lib/i386-slackware-linux/2.95.3/../../../../in
+clude/g++-3/stl_alloc.h|434]
0x001280C9 _wrap_Logger_debug+897 at
+/usr/lib/gcc-lib/i386-slackware-linux/2.95.3/../../../../include/g++-3/stl_allo
+c.h:434
0x0017A3C6 PyCFunction_Call+150 at
+/u2/src/NEW/Python-2.3/Objects/methodobject.c:77
0x001543F9 PyObject_Call+45 at
+/u2/src/NEW/Python-2.3/Objects/abstract.c:1756
0x001AF0A2 PyEval_CallObjectWithKeywords+206 at
+/u2/src/NEW/Python-2.3/Python/ceval.c:3347
0x001A4113 builtin_apply+323 at
+/u2/src/NEW/Python-2.3/Python/bltinmodule.c:106
0x0017A3C6 PyCFunction_Call+150 at
+/u2/src/NEW/Python-2.3/Objects/methodobject.c:77

from which i gather that it is choking on something in stl_alloc.h. i was under
+the impression that stl was pretty failsafe regarding memory management. i mean
+there's nothing fancy in my source files.

here are some details of my system:

gcc-2.95.3
swig-1.3.19
python-2.3

i would be very grateful if anyone had any ideas what might be causing this
+problem.

best regards,
andrew collier.

--
Andrew B. Collier
Antarctic Research Fellow tel: [phone]
Space Physics Research Institute fax: [phone]
University of Natal, Durban, 4041, South Africa