Sporadic segfaults with GCC on Ubuntu Linux #110
Description
When using GCC (tested with 4.9.3 and 5.2.1) on a Ubuntu 15.10 box one can get sporadicly but consistently segfaults when exercising the test suite enough times:
$ for i in {1..10}; do nosetests --with-doctest blosc; done ........................ ---------------------------------------------------------------------- Ran 24 tests in 5.054s OK ........................ ---------------------------------------------------------------------- Ran 24 tests in 5.368s OK ........................ ---------------------------------------------------------------------- Ran 24 tests in 5.122s OK ........................ ---------------------------------------------------------------------- Ran 24 tests in 5.184s OK ........................ ---------------------------------------------------------------------- Ran 24 tests in 5.123s OK ........................ ---------------------------------------------------------------------- Ran 24 tests in 5.753s OK ........................ ---------------------------------------------------------------------- Ran 24 tests in 5.343s OK ........................ ---------------------------------------------------------------------- Ran 24 tests in 5.133s OK ........................ ---------------------------------------------------------------------- Ran 24 tests in 5.487s OK Segmentation fault (core dumped) I cannot get any segfault when using clang (tested with 3.6 and 3.7). Testing on a Mac OSX box does not show any problem either (this is normal because xcode brings clang/LLVM).
A detailed investigation using valgrind does not show anything too evident, except things like:
test_no_leaks (blosc.test.TestCodec) ... ==5330== Invalid read of size 4 ==5330== at 0x4ECEF73: PyObject_Free (obmalloc.c:1013) ==5330== by 0x4EE2A72: tupledealloc (tupleobject.c:235) ==5330== by 0x4F327C6: ext_do_call (ceval.c:4665) ==5330== by 0x4F327C6: PyEval_EvalFrameEx (ceval.c:3026) ==5330== by 0x4F35A2D: PyEval_EvalCodeEx (ceval.c:3582) ==5330== by 0x4F34A54: fast_function (ceval.c:4446) ==5330== by 0x4F34A54: call_function (ceval.c:4371) ==5330== by 0x4F34A54: PyEval_EvalFrameEx (ceval.c:2987) ==5330== by 0x4F35A2D: PyEval_EvalCodeEx (ceval.c:3582) ==5330== by 0x4EB14A7: function_call (funcobject.c:526) ==5330== by 0x4E81D22: PyObject_Call (abstract.c:2546) ==5330== by 0x4F32796: ext_do_call (ceval.c:4663) ==5330== by 0x4F32796: PyEval_EvalFrameEx (ceval.c:3026) ==5330== by 0x4F35A2D: PyEval_EvalCodeEx (ceval.c:3582) ==5330== by 0x4EB13A0: function_call (funcobject.c:526) ==5330== by 0x4E81D22: PyObject_Call (abstract.c:2546) ==5330== Address 0x428b9020 is 32 bytes before a block of size 80,002,976 in arena "client" so perhaps there is a problem with reference counting but I am not sure if this is a red herring.
Anyway, as GCC is a very important compiler this ticket has high priority.