When you uninstalled and reinstalled python, did you remove all traces of the old python dir after running the uninstaller? Yes, I removed the directory Python23 and could not see any trace of python anymore...Does it means there really is no more trace of python? Well, it's windows, so...;-) 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? Not me, could be c++ object destruction called in different order, but how is it possible using the same executables on the same OS??? Another thing to test - try the numeric and numarray builds of matplotlib. Same problem? Bingo, this makes a difference : using Numeric, it works (no crash, can create a plot with TkAgg), but removing the Numeric matplotlib (keeping Numeric installed), and reinstalling Numarray one re-introduce the same crash...Hope this help, looks like it is numarray related anyway! 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. Thanks, we have already standardised on Numarray (seems it will be far more active and supported than Numeric in the future), so using Numeric can only be a temporary measure for me... Best regards, Greg. JDH
>>>>> "Gregory" == Gregory Lielens <gre...@ff...> writes: Gregory> Thanks, we have already standardised on Numarray (seems Gregory> it will be far more active and supported than Numeric in Gregory> the future), so using Numeric can only be a temporary Gregory> measure for me... No worries, there are a few matplotlib developers who also have more than a passing interest in numarray :-) Thanks for the clue - not sure what to make of it yet... JDH
>>>>> "Gregory" == Gregory Lielens <gre...@ff...> writes: Gregory> Bingo, this makes a difference : using Numeric, it works Gregory> (no crash, can create a plot with TkAgg), but removing Gregory> the Numeric matplotlib (keeping Numeric installed), and Gregory> reinstalling Numarray one re-introduce the same Gregory> crash...Hope this help, looks like it is numarray related Gregory> anyway! Gregory> Yes, if you have this for windows I would be happy to Gregory> test! John> OK, when I get one ready I'll post a link. Hi Gregory, I also built the 0.60b snapshot with numarray (Todd it's enough to set the NUMERIX flags in setup.py and setupext.py - no extra link stuff, right?) It works fine on my platform (winxp, enthought python2.3.3, numarray 0.9). Hope it helps, http://nitace.bsd.uchicago.edu:8080/files/share/matplotlib-0.60b.numarray.win32-py2.3.exe JDH
Hi Gregory, I also built the 0.60b snapshot with numarray (Todd it's enough to set the NUMERIX flags in setup.py and setupext.py - no extra link stuff, right?) It works fine on my platform (winxp, enthought python2.3.3, numarray 0.9). Hope it helps, http://nitace.bsd.uchicago.edu:8080/files/share/matplotlib-0.60b.numarra y.win32-py2.3.exe Sorry - still the same bug I am affraid...assertion ob_refcnt == 0 failed on line 1031 of cxx_extensions.cxx. Maybe if your debug version is available it is worth running it on my computer? Also, a wild guess but maybe the behavior mentioned by Daniele in user list is related? He seems to use about the same platform as me: numarray 0.9, python 2.3.4....although on win2000 where I did not observe any problem (I did not run it for long either, only the time to plot sin(x)...) One thing one could also try would be to compile a version without the assert in the destructor, not sure it will lead to problem but it could give more information, worth considering if it is easier than providing a "debug" version? Best regards, Greg.
On Thu, 2004年06月24日 at 12:41, John Hunter wrote: > >>>>> "Gregory" == Gregory Lielens <gre...@ff...> writes: > > > Gregory> Bingo, this makes a difference : using Numeric, it works > Gregory> (no crash, can create a plot with TkAgg), but removing > Gregory> the Numeric matplotlib (keeping Numeric installed), and > Gregory> reinstalling Numarray one re-introduce the same > Gregory> crash...Hope this help, looks like it is numarray related > Gregory> anyway! > > Gregory> Yes, if you have this for windows I would be happy to > Gregory> test! > > John> OK, when I get one ready I'll post a link. > > Hi Gregory, > > I also built the 0.60b snapshot with numarray (Todd it's enough to set > the NUMERIX flags in setup.py and setupext.py - no extra link stuff, > right?) That's all I've been doing. We're still only good for Python-2.3... Regards, Todd
Hello, I wondered if it is possible for me to compile a version of matplotlib (using numarray) from source on windows...so that I can play with the source and try to locate the origin of the strange crash I have. I have visual C++ 6.0 compiler, not sure if this is ok as my first tests usind setup.py build did not succeed (linking failed)...so is this relatively easy to do...or really better leaved to true masochists? ;-) Best regards, Greg.
>>>>> "Gregory" == Gregory Lielens <gre...@ff...> writes:
Gregory> Hello,
Gregory> I wondered if it is possible for me to compile a version
Gregory> of matplotlib (using numarray) from source on
Gregory> windows...so that I can play with the source and try to
Gregory> locate the origin of the strange crash I have. I have
Gregory> visual C++ 6.0 compiler, not sure if this is ok as my
Gregory> first tests usind setup.py build did not succeed (linking
Gregory> failed)...so is this relatively easy to do...or really
Gregory> better leaved to true masochists? ;-)
It's not too hard, and I would be very thankful if you did! I suggest
following the instructions in setupext.py. That points you to the
win32_static dir with enclosed README instructions on how to set up
mingw32. I've never built matplotlib with VC so I can't really advise
you there.
One thing that may simplify the build for you is you can turn off
BUILD_AGG, BUILD_IMAGE, BUILD_TKAGG, and BUILD_GTKAGG since you
experienced the problem with backend ps. So you should be able to
safely skip the stuff about getting GTK and Tk.
If you get it with
>>> import matplotlib
>>> matplotlib.use('PS')
>>> from matplotlib.matlab import *
The problem must be in _transforms or ft2font. Unless of course this
is a really funky bug, which it appears to be.
To narrow the focus further, you might do
# new python shell
>>> import matplotlib
>>> matplotlib.use('PS')
>>> import matplotlib._transforms
# start a new python shell
>>> import matplotlib
>>> matplotlib.use('PS')
>>> import matplotlib.ft2font
Do either of these crash ?
I'm putting my money on _transforms, since it uses numarray and
ft2font doesn't. Since you only get the crash with numarray builds,
the only logical place for the bug to be is in the _transforms module.
But will logic help us here ?!?
Another hackish debugging technique is to insert a lot of print
statements in matplotlib.matlab to find out where the crash is
occurring, ie, on which import line.
Good luck setting up the build environment.
JDH
Another hackish debugging technique is to insert a lot of print
statements in matplotlib.matlab to find out where the crash is
occurring, ie, on which import line.
Good idea, this helped me to isolate the problem:
it is in font_manager, in the createFontDict function...
Here is my output:
Import matplotlib
Matplotlib.use("PS")
Import matplotlib.font_manager
....lot of add_fname...
Add_fname
Done add_fname
Done add_decorated_fname
Assertion failed:ob_refcnt == 0 in cxx_extension.cxx, line 1031
With my "printified" createFontDict
def createFontDict(fontfiles, fontext='ttf'):
"""A function to create a dictionary of font file paths. The
default is to create a dictionary for TrueType fonts. An AFM font
dictionary can optionally be created.
"""
print "in createFontDict"
fontdict = {}
# Add fonts from list of known font files.
seen = {}
for fname in fontfiles:
if seen.has_key(fname): continue
else: seen[fname] = 1
if fontext == 'ttf':
try:
font = ft2font.FT2Font(str(fname))
except RuntimeError:
print >> sys.stderr, "Could not open font file", fname
continue
prop = ttfFontProperty(font)
elif fontext == 'afm':
try:
#print 'parsing', fname
font = afm.AFM(file(fname))
except RuntimeError:
print >> sys.stderr, "Could not open font file", fname
continue
print "calling afmFontProperty"
prop = afmFontProperty(font)
print " done"
print "add_fname"
add_filename(fontdict, prop, fname)
print "done add_fname"
# !!!! Default font algorithm needs improvement
if prop.name.lower() in ['bitstream vera serif', 'times']:
prop.name = 'serif'
add_filename(fontdict, prop, fname)
elif prop.name.lower() in ['bitstream vera sans', 'helvetica']:
prop.name = 'sans-serif'
add_filename(fontdict, prop, fname)
elif prop.name.lower() in ['zapf chancery', 'itc zapf
chancery']:
prop.name = 'cursive'
add_filename(fontdict, prop, fname)
elif prop.name.lower() in ['western', 'itc avant garde gothic']:
prop.name = 'fantasy'
add_filename(fontdict, prop, fname)
elif prop.name.lower() in ['bitstream vera sans mono',
'courier']:
prop.name = 'monospace'
add_filename(fontdict, prop, fname)
print "done add_decorated_fname"
print "now return fontdict"
return fontdict
So it seems to crash at the end of the for loop, probably on destruction
of a
Temporary object...strange, isn't it? Well, I hope it can help indentify
the problem, at least it isolated it somewhat...If you have any idea of
a test I can do for going further in the bug hunting (well, if it really
is a bug), I will be happy to do it :-)
Best regards,
Greg.
I continued investigating the crash occuring on my laptop, and found a "solution" :-) The problem occur precisely in font_manager.py, in the function createFontDict. In this function, there is a loop over a fontfiles list, that for me is made of 353 files. This loop works ok for 221 fontfiles, then crash... Now maybe this is a lot of font files compared to typical windows install, hence the crash on my system? At least I am sure this is a difference between the other WinXP and Win2000 laptop I tested, explaining why only mine did crash...I am now confident this is the origin of my Laptop problem, not some strange Voodoo malediction ;-) Why this occur with numarray and not numeric is maybe voodoo-related, though ;-)). During this Loop, special default font files are found, and renamed serif, sans-serif, cursive...in fact multiple occurrence of each default font is found (3 monospace for example)...Again, I do not understand fully the routine yet but maybe this is a problem, (especially as a comment before the default font attribution mention thet this algorithm need improvement ;-) ) I guess adding multiple fonts in the fontdict under the same name, will induce a destruction of the previous font stored with this key/name...now if prop contains a numerix array, this can explain the different behavior of numarray/numeric :-) Now if I stop the loop before this deadly 221th font, from matplotlib.matlab import * complete and I am able to plot in a TkAgg window my sin(x) :-) After that, this dictionary seems pickled in a cache and this routine is never run again, explaining maybe why this behavior was never noted: maybe it does not occur often, and once the loop has completed you are safe. I am ready to do more testing if you need more info about this, but I feel from now on maybe somebody with better knowledge of the matplotlib internals will be faster than me to locate the problem...So if I can still do something, please tell me... BTW, the matplotlib I tested is 0.60b but I had the same crash with the previous non-beta version , so I guess the problem is the same... Best regards, Greg.
>>>>> "Gregory" == Gregory Lielens <gre...@ff...> writes: Gregory> I continued investigating the crash occuring on my Gregory> laptop, and found a "solution" :-) The problem occur Gregory> precisely in font_manager.py, in the function Gregory> createFontDict. In this function, there is a loop over a Gregory> fontfiles list, that for me is made of 353 files. This Gregory> loop works ok for 221 fontfiles, then crash... Now maybe Gregory> this is a lot of font files compared to typical windows Gregory> install, hence the crash on my system? At least I am sure Gregory> this is a difference between the other WinXP and Win2000 Gregory> laptop I tested, explaining why only mine did crash...I Gregory> am now confident this is the origin of my Laptop problem, Gregory> not some strange Voodoo malediction ;-) Why this occur Gregory> with numarray and not numeric is maybe voodoo-related, Gregory> though ;-)). During this Loop, special default font Gregory> files are found, and renamed serif, sans-serif, Gregory> cursive...in fact multiple occurrence of each default Gregory> font is found (3 monospace for example)...Again, I do not Gregory> understand fully the routine yet but maybe this is a Gregory> problem, (especially as a comment before the default font Gregory> attribution mention thet this algorithm need improvement Gregory> ;-) ) I guess adding multiple fonts in the fontdict under Gregory> the same name, will induce a destruction of the previous Gregory> font stored with this key/name...now if prop contains a Gregory> numerix array, this can explain the different behavior of Gregory> numarray/numeric :-) Now if I stop the loop before this Gregory> deadly 221th font, from matplotlib.matlab import * Gregory> complete and I am able to plot in a TkAgg window my Gregory> sin(x) :-) After that, this dictionary seems pickled in a Gregory> cache and this routine is never run again, explaining Gregory> maybe why this behavior was never noted: maybe it does Gregory> not occur often, and once the loop has completed you are Gregory> safe. Gregory> I am ready to do more testing if you need more info about Gregory> this, but I feel from now on maybe somebody with better Gregory> knowledge of the matplotlib internals will be faster than Gregory> me to locate the problem...So if I can still do Gregory> something, please tell me... I doubt that it is related to the number of fonts, but your hunch that it is related to having multiple fonts that match the same attribute set sounds more likely. It would be interesting on the line before the crash to print fontdict.has_key(key) where d is the dict in question and key is the dictionary key, to see if in fact it is the replacement of a font in the dictionary that is triggering the bug. Ie, does the crash happen if and only if the dict already has the key. If so, a temporary workaround would be to do if fontdict.has_key(key): continue but I would like to get the ultimate bug fixed because these tend to come back to haunt you. Actually, it may be harder than this because if I recall correctly, fontdict is a dict of dicts of dicts... Paul may be able to offer some guidance here - he wrote the font_manager module. Though the blame for memory management rests squarely on my shoulders, in ft2font.cpp. Another thing that might be helpful is if you could zip up your font dirs and send them to me, I could try and replicate the bug on my system. If this file is too large to email, you can upload it at http://nitace.bsd.uchicago.edu:8080/files/share. Why you see this on the numarray build and not the other build is beyond me - fonts have nothing to do with numerix! Thanks for your investigations. JDH
I doubt that it is related to the number of fonts, but your hunch that it is related to having multiple fonts that match the same attribute set sounds more likely. It would be interesting on the line before the crash to print fontdict.has_key(key) where d is the dict in question and key is the dictionary key, to see if in fact it is the replacement of a font in the dictionary that is triggering the bug. Ie, does the crash happen if and only if the dict already has the key. If so, a temporary workaround would be to do if fontdict.has_key(key): continue Hum, I checked the routine a little bit more and it seems this in fact is already done: there is an auxiliary dict that exist for this purpose: not to add in the main font dict 2 times the same font...so maybe this is not the origin of the problem, I now have another idea of the origin of the problem, wich I think is related to my laptop, see below Another thing that might be helpful is if you could zip up your font dirs and send them to me, I could try and replicate the bug on my system. If this file is too large to email, you can upload it at http://nitace.bsd.uchicago.edu:8080/files/share. I tried to upload my font directory, but I did not manage to do it, maybe the website does not accept a 20 Mb file? Or there is simply too much trafic, I could try again later if needed... But what I have done is add some comments to check what happen exactly in the loop, and check which font file causes the crash: Here is the transcript: C:\Python23>python Python 2.3.4 (#53, May 25 2004, 21:17:02) [MSC v.1200 32 bit (Intel)] on win32 Type "help", "copyright", "credits" or "license" for more information. >>> from matplotlib.matlab import * importing numerix importing mlab mlab - done import division from future mlab - import sys mlab - import numerix mlab - import numerix* mlab - import cbook importing cm importing _matlab_helpers importing mlab - again importing axes -axes:done importing __future -axes:importing math,sys -axes:importing numerix -axes:importing mlab -axes:importing artist -axes:importing axis axis:imported numerix axis:imported matplotlib axis:imported patches axis:imported ticker axis:imported ticker again axis:imported transforms axis:importing font_mananger mid -font mngr 2 mid -font mngr 3 ->creating list of font path ->creating list of font dictionary -> import cPickle or pickle importing cPickle as pickle pickle.load of file C:\Python23\share\matplotlib\.ttffont.cache pickle.load failed in createFontDict 1 / 353 : C:\Python23\share\matplotlib\cmex10.ttf -> adding in dict 2 / 353 : C:\Python23\share\matplotlib\cmmi10.ttf -> adding in dict 3 / 353 : C:\Python23\share\matplotlib\cmr10.ttf -> adding in dict 4 / 353 : C:\Python23\share\matplotlib\VeraMono.ttf -> adding in dict 5 / 353 : C:\Python23\share\matplotlib\cmsy10.ttf -> adding in dict 6 / 353 : C:\Python23\share\matplotlib\VeraSeBd.ttf -> adding in dict 7 / 353 : C:\Python23\share\matplotlib\cmtt10.ttf -> adding in dict 8 / 353 : C:\Python23\share\matplotlib\Vera.ttf -> adding in dict 9 / 353 : C:\Python23\share\matplotlib\VeraBI.ttf -> adding in dict 10 / 353 : C:\Python23\share\matplotlib\VeraSe.ttf -> adding in dict 11 / 353 : C:\Python23\share\matplotlib\VeraMoIt.ttf -> adding in dict 12 / 353 : C:\Python23\share\matplotlib\VeraBd.ttf -> adding in dict 13 / 353 : C:\Python23\share\matplotlib\VeraMoBd.ttf -> adding in dict 14 / 353 : C:\Python23\share\matplotlib\VeraIt.ttf -> adding in dict 15 / 353 : C:\Python23\share\matplotlib\VeraMoBI.ttf -> adding in dict 16 / 353 : c:\windows\fonts\upcii.ttf -> adding in dict 17 / 353 : c:\windows\fonts\cordiab.ttf -> adding in dict 18 / 353 : C:\WINDOWS\Fonts\UPCFBI.TTF -> adding in dict 19 / 353 : C:\WINDOWS\Fonts\UPCJB.TTF -> adding in dict 20 / 353 : c:\windows\fonts\angsab.ttf -> adding in dict 21 / 353 : c:\windows\fonts\browai.ttf -> adding in dict 22 / 353 : C:\WINDOWS\Fonts\raavi.ttf -> adding in dict 23 / 353 : c:\windows\fonts\micross.ttf -> adding in dict 24 / 353 : C:\WINDOWS\Fonts\lvnm.ttf -> adding in dict 25 / 353 : c:\windows\fonts\times.ttf -> adding in dict 26 / 353 : c:\windows\fonts\wingdng2.ttf -> adding in dict 27 / 353 : C:\WINDOWS\Fonts\tradbdo.ttf -> adding in dict 28 / 353 : c:\windows\fonts\upcji.ttf -> adding in dict 29 / 353 : C:\WINDOWS\Fonts\ANTQUAI.TTF -> adding in dict 30 / 353 : c:\windows\fonts\trebucbd.ttf -> adding in dict 31 / 353 : c:\windows\fonts\arialnb.ttf -> adding in dict 32 / 353 : C:\WINDOWS\Fonts\BROWAUB.TTF -> adding in dict 33 / 353 : c:\windows\fonts\outlook.ttf -> adding in dict 34 / 353 : c:\windows\fonts\couri.ttf -> adding in dict 35 / 353 : c:\windows\fonts\browau.ttf -> adding in dict 36 / 353 : c:\windows\fonts\angsaz.ttf -> adding in dict 37 / 353 : c:\windows\fonts\cordiauz.ttf -> adding in dict 38 / 353 : C:\WINDOWS\Fonts\simpfxo.ttf -> adding in dict 39 / 353 : c:\windows\fonts\verdana.ttf -> adding in dict 40 / 353 : c:\windows\fonts\arial.ttf -> adding in dict 41 / 353 : c:\windows\fonts\arialn.ttf -> adding in dict 42 / 353 : C:\WINDOWS\Fonts\georgiaz.ttf -> adding in dict 43 / 353 : C:\WINDOWS\Fonts\eucsymb.ttf -> adding in dict 44 / 353 : C:\WINDOWS\Fonts\ANGSAB.TTF -> adding in dict 45 / 353 : C:\WINDOWS\Fonts\micross.ttf -> adding in dict 46 / 353 : c:\windows\fonts\tahoma.ttf -> adding in dict 47 / 353 : c:\windows\fonts\gothicb.ttf -> adding in dict 48 / 353 : c:\windows\fonts\l_10646.ttf -> adding in dict 49 / 353 : c:\windows\fonts\andlso.ttf -> adding in dict 50 / 353 : c:\windows\fonts\trebucbi.ttf -> adding in dict 51 / 353 : c:\windows\fonts\mriamfx.ttf -> adding in dict 52 / 353 : C:\WINDOWS\Fonts\arialbd.ttf -> adding in dict 53 / 353 : C:\WINDOWS\Fonts\ANGSAZ.TTF -> adding in dict 54 / 353 : C:\WINDOWS\Fonts\trebucbd.ttf -> adding in dict 55 / 353 : C:\WINDOWS\Fonts\davidbd.ttf -> adding in dict 56 / 353 : c:\windows\fonts\framd.ttf -> adding in dict 57 / 353 : c:\windows\fonts\eumat2.ttf -> adding in dict 58 / 353 : C:\WINDOWS\Fonts\cour.ttf -> adding in dict 59 / 353 : C:\WINDOWS\Fonts\verdanaz.ttf -> adding in dict 60 / 353 : C:\WINDOWS\Fonts\marlett.ttf -> adding in dict 61 / 353 : c:\windows\fonts\browauz.ttf -> adding in dict 62 / 353 : c:\windows\fonts\bookosb.ttf -> adding in dict 63 / 353 : c:\windows\fonts\euclid.ttf -> adding in dict 64 / 353 : C:\WINDOWS\Fonts\david.ttf -> adding in dict 65 / 353 : c:\windows\fonts\ariali.ttf -> adding in dict 66 / 353 : c:\windows\fonts\upcdbi.ttf -> adding in dict 67 / 353 : c:\windows\fonts\cordiai.ttf -> adding in dict 68 / 353 : C:\WINDOWS\Fonts\BROWAB.TTF -> adding in dict 69 / 353 : C:\WINDOWS\Fonts\rodtr.ttf -> adding in dict 70 / 353 : c:\windows\fonts\upcjl.ttf -> adding in dict 71 / 353 : c:\windows\fonts\simpo.ttf -> adding in dict 72 / 353 : C:\WINDOWS\Fonts\ANGSAUI.TTF -> adding in dict 73 / 353 : c:\windows\fonts\palai.ttf -> adding in dict 74 / 353 : C:\WINDOWS\Fonts\georgia.ttf -> adding in dict 75 / 353 : c:\windows\fonts\impact.ttf -> adding in dict 76 / 353 : C:\WINDOWS\Fonts\CORDIAUI.TTF -> adding in dict 77 / 353 : C:\WINDOWS\Fonts\ARIALNBI.TTF -> adding in dict 78 / 353 : C:\WINDOWS\Fonts\OUTLOOK.TTF -> adding in dict 79 / 353 : c:\windows\fonts\wingding.ttf -> adding in dict 80 / 353 : c:\windows\fonts\cordia.ttf -> adding in dict 81 / 353 : c:\windows\fonts\arialni.ttf -> adding in dict 82 / 353 : c:\windows\fonts\euextra.ttf -> adding in dict 83 / 353 : C:\WINDOWS\Fonts\lucon.ttf -> adding in dict 84 / 353 : C:\WINDOWS\Fonts\mriamfx.ttf -> adding in dict 85 / 353 : C:\WINDOWS\Fonts\euextrab.ttf -> adding in dict 86 / 353 : c:\windows\fonts\upcjb.ttf -> adding in dict 87 / 353 : c:\program files\common files\microsoft shared\equation\mtextra.ttf -> adding in dict 88 / 353 : C:\WINDOWS\Fonts\ahronbd.ttf -> adding in dict 89 / 353 : c:\windows\fonts\gothici.ttf -> adding in dict 90 / 353 : c:\windows\fonts\davidbd.ttf -> adding in dict 91 / 353 : c:\windows\fonts\comicbd.ttf -> adding in dict 92 / 353 : C:\WINDOWS\Fonts\UPCKB.TTF -> adding in dict 93 / 353 : c:\windows\fonts\arbli___.ttf -> adding in dict 94 / 353 : C:\WINDOWS\Fonts\georgiab.ttf -> adding in dict 95 / 353 : C:\WINDOWS\Fonts\GOTHICI.TTF -> adding in dict 96 / 353 : C:\WINDOWS\Fonts\UPCIB.TTF -> adding in dict 97 / 353 : C:\WINDOWS\Fonts\palai.ttf -> adding in dict 98 / 353 : C:\WINDOWS\Fonts\ARIALNB.TTF -> adding in dict 99 / 353 : c:\windows\fonts\tahomabd.ttf -> adding in dict 100 / 353 : C:\WINDOWS\Fonts\mriam.ttf -> adding in dict 101 / 353 : C:\WINDOWS\Fonts\comic.ttf -> adding in dict 102 / 353 : c:\windows\fonts\angsa.ttf -> adding in dict 103 / 353 : c:\windows\fonts\simpfxo.ttf -> adding in dict 104 / 353 : c:\windows\fonts\mangal.ttf -> adding in dict 105 / 353 : c:\windows\fonts\georgiai.ttf -> adding in dict 106 / 353 : c:\windows\fonts\upclb.ttf -> adding in dict 107 / 353 : c:\windows\fonts\comic.ttf -> adding in dict 108 / 353 : C:\WINDOWS\Fonts\ARBLI___.TTF -> adding in dict 109 / 353 : C:\WINDOWS\Fonts\ANTQUABI.TTF -> adding in dict 110 / 353 : c:\windows\fonts\pala.ttf -> adding in dict 111 / 353 : C:\WINDOWS\Fonts\nrkis.ttf -> adding in dict 112 / 353 : C:\WINDOWS\Fonts\GARA.TTF -> adding in dict 113 / 353 : C:\WINDOWS\Fonts\l_10646.ttf -> adding in dict 114 / 353 : c:\windows\fonts\lucon.ttf -> adding in dict 115 / 353 : c:\windows\fonts\arialbd.ttf -> adding in dict 116 / 353 : C:\WINDOWS\Fonts\artrbdo.ttf -> adding in dict 117 / 353 : c:\windows\fonts\estre.ttf -> adding in dict 118 / 353 : c:\windows\fonts\palab.ttf -> adding in dict 119 / 353 : C:\WINDOWS\Fonts\trado.ttf -> adding in dict 120 / 353 : C:\WINDOWS\Fonts\GOTHICBI.TTF -> adding in dict 121 / 353 : C:\WINDOWS\Fonts\CORDIA.TTF -> adding in dict 122 / 353 : c:\windows\fonts\cour.ttf -> adding in dict 123 / 353 : c:\windows\fonts\verdanaz.ttf -> adding in dict 124 / 353 : C:\WINDOWS\Fonts\rod.ttf -> adding in dict 125 / 353 : c:\windows\fonts\artro.ttf -> adding in dict 126 / 353 : C:\WINDOWS\Fonts\BROWAZ.TTF -> adding in dict 127 / 353 : C:\WINDOWS\Fonts\BOOKOSB.TTF -> adding in dict 128 / 353 : c:\windows\fonts\rod.ttf -> adding in dict 129 / 353 : c:\windows\fonts\cordiaz.ttf -> adding in dict 130 / 353 : c:\windows\fonts\tradbdo.ttf -> adding in dict 131 / 353 : c:\windows\fonts\upcjbi.ttf -> adding in dict 132 / 353 : C:\WINDOWS\Fonts\webdings.ttf -> adding in dict 133 / 353 : C:\WINDOWS\Fonts\ANGSAI.TTF -> adding in dict 134 / 353 : C:\WINDOWS\Fonts\UPCJI.TTF -> adding in dict 135 / 353 : C:\WINDOWS\Fonts\timesbd.ttf -> adding in dict 136 / 353 : c:\windows\fonts\upclbi.ttf -> adding in dict 137 / 353 : C:\WINDOWS\Fonts\UPCDBI.TTF -> adding in dict 138 / 353 : c:\windows\fonts\frank.ttf -> adding in dict 139 / 353 : C:\WINDOWS\Fonts\ANTQUAB.TTF -> adding in dict 140 / 353 : C:\WINDOWS\Fonts\CORDIAZ.TTF -> adding in dict 141 / 353 : C:\WINDOWS\Fonts\ARIALNI.TTF -> adding in dict 142 / 353 : c:\windows\fonts\antquabi.ttf -> adding in dict 143 / 353 : c:\windows\fonts\upcdb.ttf -> adding in dict 144 / 353 : C:\WINDOWS\Fonts\UPCLI.TTF -> adding in dict 145 / 353 : C:\WINDOWS\Fonts\courbi.ttf -> adding in dict 146 / 353 : C:\WINDOWS\Fonts\CORDIAUB.TTF -> adding in dict 147 / 353 : C:\WINDOWS\Fonts\GARABD.TTF -> adding in dict 148 / 353 : c:\windows\fonts\verdanab.ttf -> adding in dict 149 / 353 : c:\windows\fonts\angsau.ttf -> adding in dict 150 / 353 : c:\windows\fonts\courbi.ttf -> adding in dict 151 / 353 : c:\windows\fonts\ariblk.ttf -> adding in dict 152 / 353 : C:\WINDOWS\Fonts\UPCEBI.TTF -> adding in dict 153 / 353 : c:\windows\fonts\georgiab.ttf -> adding in dict 154 / 353 : c:\windows\fonts\wingdng3.ttf -> adding in dict 155 / 353 : C:\WINDOWS\Fonts\UPCKL.TTF -> adding in dict 156 / 353 : c:\windows\fonts\browab.ttf -> adding in dict 157 / 353 : C:\WINDOWS\Fonts\andlso.ttf -> adding in dict 158 / 353 : c:\windows\fonts\bookosbi.ttf -> adding in dict 159 / 353 : c:\windows\fonts\angsaub.ttf -> adding in dict 160 / 353 : c:\windows\fonts\upcei.ttf -> adding in dict 161 / 353 : c:\windows\fonts\upckb.ttf -> adding in dict 162 / 353 : C:\WINDOWS\Fonts\fences.ttf -> adding in dict 163 / 353 : C:\WINDOWS\Fonts\tunga.ttf -> adding in dict 164 / 353 : c:\windows\fonts\eumat2b.ttf -> adding in dict 165 / 353 : C:\WINDOWS\Fonts\BROWAUI.TTF -> adding in dict 166 / 353 : C:\WINDOWS\Fonts\wingding.ttf -> adding in dict 167 / 353 : C:\WINDOWS\Fonts\mtextra.ttf -> adding in dict 168 / 353 : c:\windows\fonts\simpbdo.ttf -> adding in dict 169 / 353 : c:\windows\fonts\davidtr.ttf -> adding in dict 170 / 353 : C:\WINDOWS\Fonts\WINGDNG2.TTF -> adding in dict 171 / 353 : C:\WINDOWS\Fonts\mvboli.ttf -> adding in dict 172 / 353 : C:\WINDOWS\Fonts\UPCJBI.TTF -> adding in dict 173 / 353 : c:\windows\fonts\browa.ttf -> adding in dict 174 / 353 : c:\windows\fonts\artrbdo.ttf -> adding in dict 175 / 353 : c:\windows\fonts\eucsym.ttf -> adding in dict 176 / 353 : C:\WINDOWS\Fonts\verdana.ttf -> adding in dict 177 / 353 : c:\windows\fonts\euclidi.ttf -> adding in dict 178 / 353 : c:\windows\fonts\bkant.ttf -> adding in dict 179 / 353 : c:\windows\fonts\upcll.ttf -> adding in dict 180 / 353 : C:\WINDOWS\Fonts\UPCDI.TTF -> adding in dict 181 / 353 : C:\WINDOWS\Fonts\verdanai.ttf -> adding in dict 182 / 353 : c:\windows\fonts\arialnbi.ttf -> adding in dict 183 / 353 : C:\WINDOWS\Fonts\eufrak.ttf -> adding in dict 184 / 353 : c:\windows\fonts\cordiaub.ttf -> adding in dict 185 / 353 : c:\windows\fonts\arialbi.ttf -> adding in dict 186 / 353 : c:\windows\fonts\eucsymb.ttf -> adding in dict 187 / 353 : c:\windows\fonts\upcdi.ttf -> adding in dict 188 / 353 : c:\windows\fonts\garabd.ttf -> adding in dict 189 / 353 : C:\WINDOWS\Fonts\eumat2b.ttf -> adding in dict 190 / 353 : C:\WINDOWS\Fonts\CORDIAU.TTF -> adding in dict 191 / 353 : c:\windows\fonts\angsauz.ttf -> adding in dict 192 / 353 : C:\WINDOWS\Fonts\BOOKOSBI.TTF -> adding in dict 193 / 353 : c:\windows\fonts\timesi.ttf -> adding in dict 194 / 353 : C:\WINDOWS\Fonts\pala.ttf -> adding in dict 195 / 353 : c:\windows\fonts\upcfl.ttf -> adding in dict 196 / 353 : C:\WINDOWS\Fonts\CORDIAUZ.TTF -> adding in dict 197 / 353 : C:\WINDOWS\Fonts\UPCLL.TTF -> adding in dict 198 / 353 : C:\WINDOWS\Fonts\simpo.ttf -> adding in dict 199 / 353 : C:\WINDOWS\Fonts\BROWAUZ.TTF -> adding in dict 200 / 353 : c:\windows\fonts\verdanai.ttf -> adding in dict 201 / 353 : C:\WINDOWS\Fonts\trebuc.ttf -> adding in dict 202 / 353 : C:\WINDOWS\Fonts\timesi.ttf -> adding in dict 203 / 353 : C:\WINDOWS\Fonts\ARIALN.TTF -> adding in dict 204 / 353 : c:\windows\fonts\trebuc.ttf -> adding in dict 205 / 353 : c:\windows\fonts\trado.ttf -> adding in dict 206 / 353 : C:\WINDOWS\Fonts\eucsymbi.ttf -> adding in dict 207 / 353 : C:\WINDOWS\Fonts\times.ttf -> adding in dict 208 / 353 : c:\windows\fonts\trebucit.ttf -> adding in dict 209 / 353 : c:\windows\fonts\angsai.ttf -> adding in dict 210 / 353 : c:\windows\fonts\upcfb.ttf -> adding in dict 211 / 353 : c:\windows\fonts\courbd.ttf -> adding in dict 212 / 353 : C:\WINDOWS\Fonts\framd.ttf -> adding in dict 213 / 353 : c:\windows\fonts\symbol.ttf -> adding in dict 214 / 353 : C:\WINDOWS\Fonts\MTCORSVA.TTF -> adding in dict 215 / 353 : C:\WINDOWS\Fonts\palab.ttf -> adding in dict 216 / 353 : c:\windows\fonts\timesbi.ttf -> adding in dict 217 / 353 : c:\windows\fonts\sylfaen.ttf -> adding in dict 218 / 353 : C:\WINDOWS\Fonts\UPCEL.TTF -> adding in dict 219 / 353 : C:\WINDOWS\Fonts\BROWAU.TTF -> adding in dict 220 / 353 : c:\windows\fonts\eumat1b.ttf -> adding in dict 221 / 353 : c:\windows\fonts\tunga.ttf -> adding in dict 222 / 353 : C:\WINDOWS\Fonts\BATANG.TTF -> adding in dict Assertion failed: ob_refcnt == 0, file CXX/cxx_extensions.cxx, line 1031 As you see, it crashes on BATANG.TTF, and this font file is not shown in the font manager and is huge (15 Mb while typical ones are aroung 100 Kb). I have to check if this is a valid font file (a priori no, but could be an asian font)...So now my guess is that adding a non-valid font (or strange one) cause an error in one of the routines that parses font files, or exceed some size somewhere, causing an unclean exit..I will check what happen if I remove this singular file, and check if this is really a font or not... I will give the info as soon as I have it, but for now it seems this is not a real bug, at most a lack of robustness when some strange files with TTF extensions are present in the font directories...so not sure it is worth considering, as it is more a question of my windows font directory beeing corrupted :-) Best regards, and thanks for your king help! Greg.
>>>>> "Gregory" == Gregory Lielens <gre...@ff...> writes: Gregory> As you see, it crashes on BATANG.TTF, and this font file Gregory> is not shown in the font manager and is huge (15 Mb while Gregory> typical ones are aroung 100 Kb). I have to check if this Gregory> is a valid font file (a priori no, but could be an asian Gregory> font)...So now my guess is that adding a non-valid font Gregory> (or strange one) cause an error in one of the routines Gregory> that parses font files, or exceed some size somewhere, Gregory> causing an unclean exit..I will check what happen if I Gregory> remove this singular file, and check if this is really a Gregory> font or not... I will give the info as soon as I have Gregory> it, but for now it seems this is not a real bug, at most Gregory> a lack of robustness when some strange files with TTF Gregory> extensions are present in the font directories...so not Gregory> sure it is worth considering, as it is more a question of Gregory> my windows font directory beeing corrupted :-) Gregory> Best regards, and thanks for your king help! Interesting - perhaps some exception is thrown in the FT2Font constructor because of the large file size) and this occurs before CXX is fully set up and its ref count is out of whack. So when the destructor is called because of the exception, the counts are bad. If there is a memory or resource related problem, perhaps the difference in the numarray and numeric builds is related to a memory footprint of those two packages. Really just free-styling here. In my casual tests, numarray does occupy a bit more memory than Numeric does. If you delete this crazy 15M font file, can you run matplotlib w/o errors? JDH
Ok, I did the test, removed this strange file (not a valid TTF file, checked that too) and everything work nicely now with 0.60b. If you want to reproduce this behavior (cannot call it a bug anymore, it is really my fault having a corrupted font directory), it is sufficient to create a non-font file in the Font directory, with TTF extension (a copy in a dos prompt is necessary, file explorer try to install the "font" on drag&drop), remove the font cache to force a rescanning, and the crash occur (using numarray, I still do not know why it worked with numeric...All I can say is that a non-valid ttf file cause a crash on matplotlib+numarray...) I do not know if nvestigating this is worthy, as nobody should have a non-valid ttf file in the font directory anyway, but maybe this will make the TTF scanning code more robust? Thanks for your help and sorry crying "Bug, bug" without real reason :-/ Best regards, Greg.