Repository navigation
Crash when saving figure with "special" text #4010
Description
(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.
Activity
QuLogic commentedon Jan 19, 2015
By following along in gdb, I've found that error is somewhat suppressed by the
throw Py::Exceptionin ft2font.cpp but it seems that this seek method fails:(Note:
close_file_callbackis called twice and it fails the second time.)QuLogic commentedon Jan 19, 2015
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 commentedon Jan 19, 2015
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 commentedon Jan 19, 2015
attn @mdboom
tacaswell commentedon Jan 19, 2015
The non-deterministic nature of this is rather worrying. That makes me suspect we have a buffer overflow someplace....
mdboom commentedon Jan 20, 2015
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 commentedon Jan 20, 2015
Yep, you're right, #4018 is just a factored out version of this one with a different symptom.