Crash when saving figure with "special" text

[QuLogic]

(This is possibly a continuation of #2635, but I am not 100% sure.)

I have not yet whittled down the problem to a simple test case, which is why I have called the text "special". If/when I can determine a smaller case, I will update the title, but I thought I'd post it here to get more eyes on the problem.

I'm sorry that the testing procedure is a bit complicated, but I hope I'll provide enough information to determine the problem. To test, you will need matplotlib 1.4.2 and the development version of ObsPy installed for Python 3 (it seem okay on Python 2). Then run the command obspy3-runtests -d obspy.imaging.tests.test_scan.ScanTestCase.test_scan (this runs only one test out of the testing framework).

Here is the shortened backtrace (or see the full backtrace here):

(gdb) bt
... Other C++ exception stuff
#5  0x00007fffe717a0b9 in __cxxabiv1::__cxa_throw (obj=0x9f6b80, tinfo=0x7fffe58671a0 <typeinfo for Py::Exception>, dest=0x0)
    at ../../../../libstdc++-v3/libsupc++/eh_throw.cc:87
#6  0x00007fffe5632239 in close_file_callback (stream=<optimized out>) at src/ft2font.cpp:2158
#7  0x00007fffe5349737 in FT_Stream_Free (stream=0x13542a0, external=1) at /usr/src/debug/freetype-2.5.3/src/base/ftobjs.c:228
#8  0x00007fffe534c7a3 in destroy_face (memory=0x1024e90, face=0x13568e0, driver=0x105e160)
    at /usr/src/debug/freetype-2.5.3/src/base/ftobjs.c:944
#9  0x00007fffe534c894 in FT_Done_Face (face=0x13568e0) at /usr/src/debug/freetype-2.5.3/src/base/ftobjs.c:2399
#10 0x00007fffe5631f3e in FT2Font::~FT2Font (this=0x1354220, __in_chrg=<optimized out>) at src/ft2font.cpp:984
#11 0x00007fffe56320d9 in FT2Font::~FT2Font (this=0x1354220, __in_chrg=<optimized out>) at src/ft2font.cpp:995
#12 0x00007fffe564b3b3 in Py::PythonClass<FT2Font>::extension_object_deallocator (_self=<FT2Font at remote 0x7fffe43d5750>)
    at extern/CXX/Python3/ExtensionType.hxx:300
#13 0x00007ffff79de4b7 in free_keys_object (keys=0x10e2bb0) at /usr/src/debug/Python-3.4.1/Objects/dictobject.c:369
...

PS, the reason I cannot shorten the example yet is that the test here runs another console script by calling its main function with the required arguments. However, if I run the console script directly, it does not crash.

[QuLogic]

By following along in gdb, I've found that error is somewhat suppressed by the throw Py::Exception in ft2font.cpp but it seems that this seek method fails:

155         ret = PyObject_CallMethod(file, "seek", MPL_OFF_T_PYFMT "i", position, 0);
(gdb) n
156         if (ret == NULL) {
(gdb) p ret
$11 = 0x0
(gdb) p PyErr_Occurred()
$12 = <type at remote 0x7ffff7d70040>
(gdb) p PyErr_PrintEx(1)
OSError: [Errno 9] Bad file descriptor
$13 = void

(Note: close_file_callback is called twice and it fails the second time.)

[QuLogic]

One other thing to note is that ~50% of the time, the crash does not occur. Out of 100 runs, 54 crashed, but none of them triggered anything in valgrind.

[QuLogic]

Bisect points to 0c0ff8b, though since that just introduces error checking, it's possible the problem existed before then (and I have a feeling it's f4adec7 like #2635).

[tacaswell]

attn @mdboom

[tacaswell]

The non-deterministic nature of this is rather worrying. That makes me suspect we have a buffer overflow someplace....

[mdboom]

If this is being run in the context of the output handling code in #4018, this definitely could be a dupe (and thus outside of matplotlib). @QuLogic: Would you mind testing this in the context of the fixed output-redirecting handler, and reopen if that doesn't fix this issue as well. The unpredictable nature of this would be consistent with the file handle brokenness in #4018.

[QuLogic]

Yep, you're right, #4018 is just a factored out version of this one with a different symptom.