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! Thanks a lot, and congratulation for matplotlib, it looks the most promising python plotting packages I have found yet! :-)
>>>>> "Gregory" == Gregory Lielens <gre...@ff...> writes: Gregory> I checked on another WinXP computer, and it works on this Gregory> one - seems that I have to play the windows re-install Gregory> game, or hunt down what the exact differences between Gregory> these 2 WinXP computers are :-/... The fact that only Gregory> matplotlib exhibit this behavior is strange though, I Gregory> checked in the code (hence cc to the devel list) and the Gregory> problem is linked to an assert in the destructor of Gregory> PythonExtensionBase, checking that the ref counting of Gregory> this object is 0 and exiting Python interpreter if it is Gregory> not the case...Hum, obviously I do not know the code at Gregory> all, but could the problem be linked to a destruction Gregory> sequence beeing somewhat different on my computer (for Gregory> whatever reasons :-/)? This worry me (in addition to Gregory> bother me not beeing able to run matplotlib on my laptop Gregory> for the moment ;-) ), cause it may be the sign of Gregory> "difficult to solve and reproduce" installation problems Gregory> for a package we may use in a distributed software Gregory> package in the future... I will keep investigating, but Gregory> if there is a developer have any idea about this (like, a Gregory> hint about why there is this assert there and what can Gregory> 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
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. Thanks for this explanation, it could thus be related to a hard to reproduce bug (why hard to reproduce? see below) 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. It looks more like it is specific to my laptop, cause installing exactly the same python, numarray and matplotlib on another winXP laptop did not showed the behavior. It will thus be a hard to reproduce bug, cause I find only one computer exhibiting this behavior for now (on the other hand, the behavior of this computer is very reliable: systematic crash all the time, even after python/nuamrray/matplotlib reinstall ). If I try to install another version of python on this laptop (python 2.3.3), it crashes the same...I could try older versions (2.2.3 for example), but 2.3.X is required for numarray 0.9 so I should go to older version there also, I prefer to do it only if you find it usefull... * 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. Yes, exactly the same crash, and with PS backend also...so it does not seems related to the backend... 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. Yes, if you have this for windows I would be happy to test! It's me that thanks you for your help! Best regards, Greg.
>>>>> "Gregory" == Gregory Lielens <gre...@ff...> writes: Gregory> It looks more like it is specific to my laptop, cause Gregory> installing exactly the same python, numarray and Gregory> matplotlib on another winXP laptop did not showed the Gregory> behavior. It will thus be a hard to reproduce bug, cause Gregory> I find only one computer exhibiting this behavior for now Gregory> (on the other hand, the behavior of this computer is very Gregory> reliable: systematic crash all the time, even after Gregory> python/nuamrray/matplotlib reinstall ). If I try to Gregory> install another version of python on this laptop (python Gregory> 2.3.3), it crashes the same...I could try older versions Gregory> (2.2.3 for example), but 2.3.X is required for numarray Gregory> 0.9 so I should go to older version there also, I prefer Gregory> to do it only if you find it usefull... No, I wouldn't ask you to try python 2.2! I asked about 2.3.3 because matplotlib has been used by many people on windows with that version whereas 2.3.4 is comparatively new. Just a shot in the dark really. When you uninstalled and reinstalled python, did you remove all traces of the old python dir after running the uninstaller? It's strikes me as very odd that the same python + numarray + matplotlib + operating system would generate different reference counting behavior. Can anyone think of a possible explanation for this? Another thing to test - try the numeric and numarray builds of matplotlib. Remove C:\Python23\lib\site-packages\matplotlib *and* C:\Python23\share\matplotlib and then install and test * numeric build -= http://prdownloads.sourceforge.net/matplotlib/matplotlib-0.54.2.win32-py2.3.exe?download * remove the dirs above and then try the numarray build http://prdownloads.sourceforge.net/matplotlib/matplotlib-0.54.2-numarray0.9.win32-py2.3.exe?download Same problem? Gregory> Yes, if you have this for windows I would be happy to Gregory> test! OK, when I get one ready I'll post a link. JDH