matplotlib-devel Mailing List for matplotlib

On Fri, Mar 27, 2009 at 5:11 PM, John Hunter <jd...@gm...> wrote:

> On Fri, Mar 27, 2009 at 1:23 PM, Karen Tracey <kmt...@gm...> wrote:
>
>> With the above change to make the texd and _fontd caches per-instance, the
>> script has finished successfully 4 times.  Seems pretty convincing evidence
>> that it fixes the problem.
>>
>
> OK,  I made this change to svn r7008.  We probably do not gain *that much*
> by caching across renderers anyhow.
>
>

Cool, thanks!


>
>>
>> Also, make sure you have disabled usetex in matplotlibrc, since the use of
>>> the filesystem for caching the tex datafiles is probably not thread safe.
>>> My guess is that the font cache on the file system is not thread safe
>>> either, but this may only affect the first run of mpl after a clean install.
>>>
>>
>> Not sure what matplotlibrc is?  I found a file
>> /usr/share/matplotlib/matplotlib.conf that has usetex set to False.  Is that
>> it?  If so I guess it's been disabled all along, this is not something I
>> have fiddled with.
>>
>
> matplotlib.conf is an experimental config that is no longer in use (but it
> won't hurt you to have it lying around).  See
> http://matplotlib.sourceforge.net/users/customizing.html for details on
> the matplotlibrc file
>

Hmm, the Ubuntu packaging for matplotlib seems to put a copy of matplotlibrc
only in /etc, where, I gather, it will not ever be used by matplotlib?  I
guess one is supposed to copy it to one's home directory and do per-user
customization there.  For my case, where the code is running under Apache,
I'd guess no matplotlibrc is being found so all defaults are being used.

>
> No need for data files -- just use np.random.rand to make up some random
> data for plotting.  That keeps things simple and small, and you can post the
> script to the list, and hopefully we can find a home for it in our unit
> tests.
>

OK, I reduced it to a bare minimum, using random data.  I removed stuff that
was in my code like customizing colors, highlighting a particular bar, and
even setting of the title and axis labels since it turns out none of that is
necessary to trip the exception.  I'll append below a script that reliably
reproduces the error on my machine.  8 threads at 50 iterations seems sure
to hit it, fewer threads or fewer iterations may not.  Hope this is helpful,
Karen

#! /usr/bin/python
import os
import threading
import traceback

import numpy as np
from matplotlib.backends.backend_agg import FigureCanvasAgg as FigureCanvas
from matplotlib.figure import Figure

thread_count = 8
max_iterations = 50
exception_raised = False

def png_thread(tn):
    png_fname = 'out%d.png' % tn
    vals = 100 + 15 * np.random.randn(10000)

    i = 0
    excp = None
    global exception_raised
    while not exception_raised and i < max_iterations:
        i += 1
        png_f = open(png_fname, 'wb')

        try:
            fig = Figure()
            ax = fig.add_subplot(111)
            ax.hist(vals, 50)
            FigureCanvas(fig).print_png(png_f)
        except Exception, excp:
            pass

        png_f.close()
        if excp:
            print 'png_thread %d failed on iteration %d:' % (tn, i)
            print traceback.format_exc(excp)
            exception_raised = True
        else:
            print 'png_thread %d completed iteration %d.' % (tn, i)

    os.unlink(png_fname)

def main(tc):
    threads = []
    for i in range(tc):
        threads.append(threading.Thread(target=png_thread, args=(i+1,)))

    for t in threads:
        t.start()

    for t in threads:
        t.join()

    if not exception_raised:
        msg = 'Success! %d threads completed %d iterations with no
exceptions raised.'
    else:
        msg = 'Failed! Exception raised before %d threads completed %d
iterations.'

    print msg % (tc, max_iterations)

if __name__== "__main__":
    main(thread_count)