Re: [matplotlib-devel] crash on matplotlib.matlab import on win32 - solution and question...

[John H. <jdh...@ac...>]

>>>>> "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