Bug#940679: pandas: random test crashes
Control: tags -1 - patch That's not the problem: cdef classes _can_ have non-cdef class (not instance) attributes. https://github.com/cython/cython/issues/3154 On further inspection, the actual problem is that we have a Timedelta (full Python class, has a dict) allocated in a memory space sized for its parent _Timedelta (cdef class, no dict). I don't know how this happened: the _Timedelta C struct is only created via its tp_new, which is passed the subclass (the standard Python mechanism for allowing subclasses to be larger in memory than their parent class - https://docs.python.org/3/c-api/typeobj.html#c.PyTypeObject.tp_new). -- debian-science-maintainers mailing list debian-science-maintainers@alioth-lists.debian.net https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/debian-science-maintainers
Processed: Re: Bug#940679: pandas: random test crashes
Processing control commands: > tags -1 - patch Bug #940679 [src:pandas] pandas: random test crashes Removed tag(s) patch. -- 940679: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=940679 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems -- debian-science-maintainers mailing list debian-science-maintainers@alioth-lists.debian.net https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/debian-science-maintainers
Bug#940679: pandas: random test crashes
There's also a few more of these: https://salsa.debian.org/science-team/pandas/commit/c6fc5d5ccbec7ca833ca6d2556ab7013aff4b065 However, the above fix doesn't work: cdef attributes can't have default values. -- debian-science-maintainers mailing list debian-science-maintainers@alioth-lists.debian.net https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/debian-science-maintainers
Bug#940679: pandas: random test crashes
Control: tags -1 patch Running the test suite (of -7) under gdb a few times produced a crash in pandas/tests/indexes/interval/test_astype.py::TestDatetimelikeSubtype::test_astype_category[index4] (4 not 3). The trace points to Cython-generated C from _Timedelta._has_ns, which (among other things) tries to dereference ((PyDictObject*)((_PyObject_GetDictPtr(((PyObject *)__pyx_v_self). (gdb) p (__pyx_v_self) $18 = (struct __pyx_obj_6pandas_5_libs_6tslibs_10timedeltas__Timedelta *) 0x7fff8ee09f70 (gdb) p *((PyDictObject*)((_PyObject_GetDictPtr(((PyObject *)__pyx_v_self) Cannot access memory at address 0x7fff8ee0a000 # __pyx_v_self+144 (gdb) p ((PyDictObject*)((_PyObject_GetDictPtr(((PyObject *)__pyx_v_self) $5 = (PyDictObject *) 0x7fff8ee09ff0 # __pyx_v_self+128 (gdb) p sizeof(PyDictObject) $28 = 48 # if it starts at +128, it ends at +176 (gdb) p ((PyObject *)__pyx_v_self)->ob_type->tp_dictoffset $25 = 128 (gdb) p ((PyObject *)__pyx_v_self)->ob_type->tp_weaklistoffset $29 = 136 (gdb) p ((PyObject *)__pyx_v_self)->ob_type->tp_basicsize $26 = 144 (gdb) p sizeof(*(__pyx_v_self)) $21 = 128 # PyDictObject is off the end of the C struct This looks like Python thinks _Timedelta has a per-instance dict, but C thinks it doesn't and so doesn't allocate space for it, and the crash happens when Python tries to read off the end. I suspect this is because cdef classes aren't supposed to have non-cdef attributes, which makes this an easy problem to fix: --- a/pandas/_libs/tslibs/timedeltas.pyx +++ b/pandas/_libs/tslibs/timedeltas.pyx @@ -655,7 +655,7 @@ cdef class _Timedelta(timedelta): int64_t _d, _h, _m, _s, _ms, _us, _ns # higher than np.ndarray and np.matrix -__array_priority__ = 100 +cdef public object __array_priority__ = 100 def __hash__(_Timedelta self): if self._has_ns(): but the Cython documentation is ambiguous as to whether this is actually prohibited, and I haven't tested it yet. -- debian-science-maintainers mailing list debian-science-maintainers@alioth-lists.debian.net https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/debian-science-maintainers
Processed: Re: Bug#940679: pandas: random test crashes
Processing control commands: > tags -1 patch Bug #940679 [src:pandas] pandas: random test crashes Added tag(s) patch. -- 940679: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=940679 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems -- debian-science-maintainers mailing list debian-science-maintainers@alioth-lists.debian.net https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/debian-science-maintainers
Bug#940679: pandas: random test crashes
The ppc64 failure was this bug, specifically the pandas/tests/indexes/interval/test_astype.py::TestDatetimelikeSubtype::test_astype_category[index3] version. It was retried successfully. (The hppa failure is something else.) The "Build environment" section of the build log (i.e. the versions of all installed packages, both build-essential and explicit dependencies) is identical between the failed and successful attempts. pandas isn't fully reproducible, but the -lib parts (i.e. where one can get a segfault as opposed to an exception) are (https://tests.reproducible-builds.org/debian/rb-pkg/unstable/armhf/diffoscope-results/pandas.html), so this suggests the randomness is per test run not per build. And hence that it only happens when running more than just these tests (given that it didn't happen in far more attempts of that). debci has one failure that _might_ be this (it's old enough that the log has been deleted) out of ~140 attempts, which suggests the bug is new. (Or newly exposed: maybe by locales-all, added as a build/test dependency in -5?) -- debian-science-maintainers mailing list debian-science-maintainers@alioth-lists.debian.net https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/debian-science-maintainers
Bug#940679: pandas: random test crashes
Hello Rebecca, >Running just the affected test files (in installed -6) produced no >failures in ~350 attempts. The build of -7 succeeded on amd64; it >failed on ppc64, but as the log isn't available yet, I don't know if >it's this bug. I don't think so, when log is not available it might mean a powercycle of the builder, or something else (e.g. space issue).It has been probably automatically retried and now it passed >While both tests involve time-related dtypes, the test data is a fixed >set not the current time, so the time of build probably isn't what >decides which runs fail. > >Does anyone have a reproducible way to trigger this error? nope, and looks like they are all good now :) close this bug and keep an eye for the future might be the bet thing to do I would say...thanks for the effort and for unbreaking the pandas loop! G. -- debian-science-maintainers mailing list debian-science-maintainers@alioth-lists.debian.net https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/debian-science-maintainers
Bug#940679: pandas: random test crashes
Control: tags -1 unreproducible Running just the affected test files (in installed -6) produced no failures in ~350 attempts. The build of -7 succeeded on amd64; it failed on ppc64, but as the log isn't available yet, I don't know if it's this bug. While both tests involve time-related dtypes, the test data is a fixed set not the current time, so the time of build probably isn't what decides which runs fail. Does anyone have a reproducible way to trigger this error? -- debian-science-maintainers mailing list debian-science-maintainers@alioth-lists.debian.net https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/debian-science-maintainers
Processed: Re: Bug#940679: pandas: random test crashes
Processing control commands: > tags -1 unreproducible Bug #940679 [src:pandas] pandas: random test crashes Added tag(s) unreproducible. -- 940679: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=940679 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems -- debian-science-maintainers mailing list debian-science-maintainers@alioth-lists.debian.net https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/debian-science-maintainers
