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: +27 31 2601157
Space Physics Research Institute fax: +27 31 2616550
University of Natal, Durban, 4041, South Africa