swig and mpatrol

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 been struggling with the following problem for a couple of days now. 
specifically, i have a logger class within a larger project. i built the 
project with mpatrol a little while ago 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/../../../../include/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_alloc.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

----- End forwarded message -----

-- 
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
_______________________________________________
Swig maillist  -  Swig@xxxxxxxxxxxxxxx
http://mailman.cs.uchicago.edu/mailman/listinfo/swig