-
Notifications
You must be signed in to change notification settings - Fork 76
Closed
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.
Metadata
Metadata
Assignees
Labels
No labels