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 = "xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx"
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