RE : RE : crash on matplotlib.matlab import on win32

Development matplotlib-devel
1

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? :wink:

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

2

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 :slight_smile:

Best regards,

Greg.

3

I continued investigating the crash occuring on my laptop, and found a
"solution" :slight_smile:
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 :wink: 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 :wink: ) 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 :slight_smile:
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) :slight_smile:
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.