I checked on another WinXP computer, and it works on this
> one - seems that I have to play the windows re-install
> game, or hunt down what the exact differences between
> these 2 WinXP computers are :-/... The fact that only
> matplotlib exhibit this behavior is strange though, I
> checked in the code (hence cc to the devel list) and the
> problem is linked to an assert in the destructor of
> PythonExtensionBase, checking that the ref counting of
> this object is 0 and exiting Python interpreter if it is
> not the case...Hum, obviously I do not know the code at
> all, but could the problem be linked to a destruction
> sequence beeing somewhat different on my computer (for
> whatever reasons :-/)? This worry me (in addition to
> bother me not beeing able to run matplotlib on my laptop
> for the moment ), cause it may be the sign of
> "difficult to solve and reproduce" installation problems
> for a package we may use in a distributed software
> package in the future... I will keep investigating, but
> if there is a developer have any idea about this (like, a
> hint about why there is this assert there and what can
> cause it to fail), it would be great!
CXX is the python wrapper generator code used to write most of the C++
python extensions that matplotlib uses. Among other things, it helps
automate reference counting for python objects, but in many cases
needs some assistance from the operator (me). Since I've been
actively working on the reference counts in a number of parts of the
code to fix some memory leaks, there is a good chance that I screwed
up somewhere.
There are two things that would be useful to know:
* Is this specific to python 2.3.4? Is this the same version of
python on all the machines you tested, or is there a difference
between the python versions on the machines that crashed and the
machine that worked? I also tested on Windows XP with no
problems, using the enthought edition of python.
* If instead of importing TkAgg, you simply import Agg, on a machine
that crashes, do you still get the crash? It would be nice to
narrow the focus.
I have done a fair amount of work since 0.54.2 fixing more memory
leaks - there is always a possibility that the problem has already
been fixed. If you can provide the information above, I can send you
a debug build of the current development snapshot that might provide
more information. Basically, it prints each function call to
stdout which sometimes help debug a segfault and other errors.
Thanks for your help,
JDH