[pyicu-dev] Memory Leak?

[David Bolen]

Andi Vajda wrote:

> Actually, I tried to replace -nodefault with -nodefaultctor and rebuild all 
> with swig 1.3.28 and the destructor code was generated and these warnings 
> didn't appear anymore.

Yes, that now matches with my experience.  Or at least, while in some
tests I'm still seeing some incremental growth, barring much more
strenuous testing, it feels well within what just some normal working
set slush might be.

> Indeed. Apart from probably not rebuilding it correctly, you didn't
> do anything wrong. I, however, did something completely wrong by
> using -nodefault when what I really wanted was -nodefaultctor, that
> is, no constructor code generation by default, only generate code
> for constructors that I declare.

Which was the missing link for me.  I wasn't sure why -nodefault had been
chosen so wasn't sure what to change.

> So, apparently, the fix to this is simple:
> 
>    - use -nodefaultctor instead of -nodefault
>    - and use swig 1.3.28 since -nodefaultctor doesn't appear to be supported
>      with swig 1.3.24

I think so yes.  I did find the news for swig 1.3.28 as adding this finer
grained constructor/destructor control to help avoid these kinds of memory
leaks, so it looks like a nice confluence of events.

> I haven't done any other testing of PyICU with swig 1.3.28 and would 
> appreciate it if you could report back about how it is working for you.
> Every swig upgrade introduces a dose of unknowns...

So far other than the memory issue I've had no real problems, but I'm
just in an "investigation" mode so may not give it real heavy use in
the near term.  The only other issues I think are more ICU than the
wrapper (such as how to detect if creating a locale-aware object such
as NumberFormat is given a locale for which it has no data).

About the only thing that I would find nice is if PyICU could continue
to support building for Python 2.3, since a number of our systems are
still using it.  Handling the lack of Py_RETURN_NONE seems easy enough
(just define it if not present), but the lack of a datetime object in
the C layer might be a little more insurmountable or at least
impractical.  Even if the code just skipped supportinga such a return
value when compiled for 2.3, it would be a little more convenient for
building without needing local modification.

-- David