Summary: | dev-python/cython-0.29.21-r1 fails tests pyarray.test_extend, pyarray.test_extend_buffer (segmentation fault) | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | Kent Fredric (IRC: kent\n) (RETIRED) <kentnl> |
Component: | Current packages | Assignee: | Python Gentoo Team <python> |
Status: | RESOLVED FIXED | ||
Severity: | normal | CC: | m68k |
Priority: | Normal | Keywords: | TESTFAILURE |
Version: | unspecified | ||
Hardware: | All | ||
OS: | Linux | ||
See Also: |
https://bugs.gentoo.org/show_bug.cgi?id=750386 https://bugs.gentoo.org/show_bug.cgi?id=751526 |
||
Whiteboard: | |||
Package list: | Runtime testing required: | --- | |
Attachments: |
build.log.gz
pyarray test .so and coredump |
Description
Kent Fredric (IRC: kent\n) (RETIRED)
2020-10-20 00:02:54 UTC
I've replicated this under QEmu-System now, segfaults in the same place. Alas, no dmesg, still. And everything I've tried to re-run *just* the failing test in a way I can expect to understand anything about what's going wrong just fails, and starts the whole (21 hour) test suite from scratch. I'm probably just gonna mask USE="test" in package.use.mask on the m68k profile unless somebody can even tell me how to provide information that indicates *what* the problem is, (let alone, working out how to solve it) Also worth mentioning there are other FAILS in the test log, just none so critical as to abort the entire test other than this. Doctest: numpy_memoryview.__test__.test_coerce_to_numpy ... FAIL Doctest: numpy_memoryview.test_coerce_to_numpy ... FAIL Doctest: numpy_memoryview.__test__.test_coerce_to_numpy ... FAIL Doctest: numpy_memoryview.test_coerce_to_numpy ... FAIL Doctest: pyarray.test_extend ... FAIL Though I also suspect something in the *harness* is panicking, which makes this even more fun. Created attachment 668843 [details]
pyarray test .so and coredump
Ok, Manged to replicate the extend segfault in iso:
cd tests/run
cp pyarray.pyx pyarrayng.pyx
echo 'print(test_extend_buffer())' >> pyarrayng.pyx
cythonize -i pyarrayng.pyx
python -c "import pyarrayng"
^ this segfaults.
However, I don't have tools yet to poke into the actual failure -_-
Attached has a coredump and the .so blamed.
Now confirming the same segfault happens on all of: qemu-m68k qemu-system-m68k aranym-mmu Finally, after a lot of self abuse: Program received signal SIGSEGV, Segmentation fault. 0x3f4a1c64 in memcpy () from /mnt/btrfs/vm/m68k/native-img-0/mount/lib/libc.so.6 #0 0x3f4a1c64 in memcpy () from /mnt/btrfs/vm/m68k/native-img-0/mount/lib/libc.so.6 #1 0x00000004 in ?? () #2 0x3ecb9dca in ?? () #3 0x00087dc2 in ?? () #4 0x3ee7a3a0 in ?? () #5 0x3ee40000 in _DYNAMIC () from /mnt/btrfs/vm/m68k/native-img-0/mount/var/tmp/portage/dev-python/cython-0.29.21-r1/work/cython-0.29.21/tests/run/pyarrayng.cpython-37m-m68k-linux-gnu.so #6 0x3ee25258 in memcpy (__len=16981, __src=<optimized out>, __dest=<optimized out>) at /usr/include/bits/string_fortified.h:34 #7 __pyx_f_7cpython_5array_extend_buffer (__pyx_v_n=2, __pyx_v_stuff=<optimized out>, __pyx_v_self=0x3ecbd0cc) at /var/tmp/portage/dev-python/cython-0.29.21-r1/work/cython-0.29.21/tests/run/pyarrayng.c:5465 #8 __pyx_pf_9pyarrayng_28test_extend_buffer (__pyx_self=<optimized out>) at /var/tmp/portage/dev-python/cython-0.29.21-r1/work/cython-0.29.21/tests/run/pyarrayng.c:4880 #9 __pyx_pw_9pyarrayng_29test_extend_buffer (__pyx_self=0x0, unused=0x0) at /var/tmp/portage/dev-python/cython-0.29.21-r1/work/cython-0.29.21/tests/run/pyarrayng.c:4805 #10 0x3ee29798 in __Pyx_PyObject_CallMethO (arg=0x0, func=0x3ee7c66c) at /var/tmp/portage/dev-python/cython-0.29.21-r1/work/cython-0.29.21/tests/run/pyarrayng.c:22517 #11 __Pyx_PyObject_CallNoArg (func=0x3ee7c66c) at /var/tmp/portage/dev-python/cython-0.29.21-r1/work/cython-0.29.21/tests/run/pyarrayng.c:23587 #12 __pyx_pymod_exec_pyarrayng (__pyx_pyinit_module=0x3ee76c34) at /var/tmp/portage/dev-python/cython-0.29.21-r1/work/cython-0.29.21/tests/run/pyarrayng.c:20609 #13 0x3f619670 in PyModule_ExecDef () from /mnt/btrfs/vm/m68k/native-img-0/mount/usr/lib/libpython3.7m.so.1.0 #14 0x3ee76c34 in ?? () #15 0x3ee41c28 in __pyx_string_tab () from /mnt/btrfs/vm/m68k/native-img-0/mount/var/tmp/portage/dev-python/cython-0.29.21-r1/work/cython-0.29.21/tests/run/pyarrayng.cpython-37m-m68k-linux-gnu.so #16 0x3ee76c34 in ?? () #17 0x3f7fd1d4 in __pointer_chk_guard () from /mnt/btrfs/vm/m68k/native-img-0/mount/lib/ld.so.1 #18 0x3f779000 in ?? () from /mnt/btrfs/vm/m68k/native-img-0/mount/usr/lib/libpython3.7m.so.1.0 #19 0x3f6a5138 in ?? () from /mnt/btrfs/vm/m68k/native-img-0/mount/usr/lib/libpython3.7m.so.1.0 #20 0x3ee76c34 in ?? () #21 0x3ee41c28 in __pyx_string_tab () from /mnt/btrfs/vm/m68k/native-img-0/mount/var/tmp/portage/dev-python/cython-0.29.21-r1/work/cython-0.29.21/tests/run/pyarrayng.cpython-37m-m68k-linux-gnu.so #22 0x00000008 in ?? () #23 0x3f7a0b2e in ?? () from /mnt/btrfs/vm/m68k/native-img-0/mount/usr/lib/libpython3.7m.so.1.0 #24 0x3f779000 in ?? () from /mnt/btrfs/vm/m68k/native-img-0/mount/usr/lib/libpython3.7m.so.1.0 #25 0x3f5e530a in _PyMethodDef_RawFastCallDict () from /mnt/btrfs/vm/m68k/native-img-0/mount/usr/lib/libpython3.7m.so.1.0 #26 0x3f5e5372 in _PyCFunction_FastCallDict () from /mnt/btrfs/vm/m68k/native-img-0/mount/usr/lib/libpython3.7m.so.1.0 #27 0x3f7a0b2e in ?? () from /mnt/btrfs/vm/m68k/native-img-0/mount/usr/lib/libpython3.7m.so.1.0 #28 0x3eed048c in ?? () #29 0x3eebc178 in ?? () #30 0x00000001 in ?? () #31 0x3ee65464 in ?? () #32 0x3ee65464 in ?? () #33 0x3eedc2fc in ?? () #34 0x3eedc2fc in ?? () #35 0x3f5e636a in PyCFunction_Call () from /mnt/btrfs/vm/m68k/native-img-0/mount/usr/lib/libpython3.7m.so.1.0 #36 0x3eedc2fc in ?? () #37 0x3eebc178 in ?? () #38 0x00000001 in ?? () #39 0x3ee65464 in ?? () #40 0x3ee65464 in ?? () #41 0x3eedc2fc in ?? () #42 0x3f7d8670 in Py_DebugFlag () from /mnt/btrfs/vm/m68k/native-img-0/mount/usr/lib/libpython3.7m.so.1.0 #43 0x3ee45d84 in ?? () #44 0x3ee45c44 in ?? () #45 0x3eec45d8 in ?? () #46 0x3f779000 in ?? () from /mnt/btrfs/vm/m68k/native-img-0/mount/usr/lib/libpython3.7m.so.1.0 #47 0x3fffdf84 in ?? () #48 0x3f5c6a5c in _PyEval_EvalFrameDefault () from /mnt/btrfs/vm/m68k/native-img-0/mount/usr/lib/libpython3.7m.so.1.0 #49 0x3f68ffea in PyEval_EvalFrameEx () from /mnt/btrfs/vm/m68k/native-img-0/mount/usr/lib/libpython3.7m.so.1.0 #50 0x3ee45c44 in ?? () #51 0x00000000 in ?? () Dump of assembler code for function memcpy: 0x3f4a1bd4 <+0>: moveml %d2-%d4/%a2/%a5,%sp@- 0x3f4a1bd8 <+4>: moveal %sp@(24),%a0 0x3f4a1bdc <+8>: movel %sp@(28),%d2 0x3f4a1be0 <+12>: movel %sp@(32),%d0 0x3f4a1be4 <+16>: moveal %a0,%a2 0x3f4a1be6 <+18>: moveal %d2,%a1 0x3f4a1be8 <+20>: moveq #15,%d1 0x3f4a1bea <+22>: cmpl %d0,%d1 0x3f4a1bec <+24>: bccw 0x3f4a1c7a <memcpy+166> 0x3f4a1bf0 <+28>: movel %a0,%d1 0x3f4a1bf2 <+30>: negl %d1 0x3f4a1bf4 <+32>: moveq #3,%d3 0x3f4a1bf6 <+34>: andl %d3,%d1 0x3f4a1bf8 <+36>: subl %d1,%d0 0x3f4a1bfa <+38>: tstl %d1 0x3f4a1bfc <+40>: beqw 0x3f4a1c96 <memcpy+194> 0x3f4a1c00 <+44>: movel %d1,%d3 0x3f4a1c02 <+46>: addl %a0,%d3 0x3f4a1c04 <+48>: moveb %a1@+,%a2@+ 0x3f4a1c06 <+50>: cmpl %a2,%d3 0x3f4a1c08 <+52>: bnes 0x3f4a1c04 <memcpy+48> 0x3f4a1c0a <+54>: moveal %d2,%a1 0x3f4a1c0c <+56>: addal %d1,%a1 0x3f4a1c0e <+58>: movel %d0,%d4 0x3f4a1c10 <+60>: lsrl #5,%d4 0x3f4a1c12 <+62>: bfextu %d0,27,3,%d1 0x3f4a1c16 <+66>: moveq #8,%d2 0x3f4a1c18 <+68>: subl %d1,%d2 0x3f4a1c1a <+70>: lsll #2,%d2 0x3f4a1c1c <+72>: moveal %d3,%a2 0x3f4a1c1e <+74>: subal %d2,%a2 0x3f4a1c20 <+76>: subal %d2,%a1 0x3f4a1c22 <+78>: addl %d1,%d1 0x3f4a1c24 <+80>: movew %pc@(0x3f4a1c2c <memcpy+88>,%d1:l),%d1 0x3f4a1c28 <+84>: jmp %pc@(0x3f4a1c2c <memcpy+88>,%d1:w) 0x3f4a1c2c <+88>: .short 0x003e 0x3f4a1c2e <+90>: orib #50,0x2c 0x3f4a1c34 <+96>: orib #32,%fp@- 0x3f4a1c38 <+100>: orib #20,%a2@+ 0x3f4a1c3c <+104>: movel %a1@,%a2@ 0x3f4a1c3e <+106>: subql #1,%d4 0x3f4a1c40 <+108>: movel %a1@(4),%a2@(4) 0x3f4a1c46 <+114>: movel %a1@(8),%a2@(8) 0x3f4a1c4c <+120>: movel %a1@(12),%a2@(12) 0x3f4a1c52 <+126>: movel %a1@(16),%a2@(16) 0x3f4a1c58 <+132>: movel %a1@(20),%a2@(20) 0x3f4a1c5e <+138>: movel %a1@(24),%a2@(24) => 0x3f4a1c64 <+144>: movel %a1@(28),%a2@(28) And here's the generated C code for the failure point: 5419 static CYTHON_INLINE int __pyx_f_7cpython_5array_extend_buffer(arrayobject *__pyx_v_self, char *__pyx_v_stuff, Py_ssize_t __pyx_v_n) { 5420 Py_ssize_t __pyx_v_itemsize; 5421 Py_ssize_t __pyx_v_origsize; 5422 int __pyx_r; 5423 __Pyx_RefNannyDeclarations 5424 int __pyx_t_1; 5425 int __pyx_lineno = 0; 5426 const char *__pyx_filename = NULL; 5427 int __pyx_clineno = 0; 5428 __Pyx_RefNannySetupContext("extend_buffer", 0); 5429 5430 /* "array.pxd":149 5431 * (e.g. of same array type) 5432 * n: number of elements (not number of bytes!) """ 5433 * cdef Py_ssize_t itemsize = self.ob_descr.itemsize # <<<<<<<<<<<<<< 5434 * cdef Py_ssize_t origsize = Py_SIZE(self) 5435 * resize_smart(self, origsize + n) 5436 */ 5437 __pyx_t_1 = __pyx_v_self->ob_descr->itemsize; 5438 __pyx_v_itemsize = __pyx_t_1; 5439 5440 /* "array.pxd":150 5441 * n: number of elements (not number of bytes!) """ 5442 * cdef Py_ssize_t itemsize = self.ob_descr.itemsize 5443 * cdef Py_ssize_t origsize = Py_SIZE(self) # <<<<<<<<<<<<<< 5444 * resize_smart(self, origsize + n) 5445 * memcpy(self.data.as_chars + origsize * itemsize, stuff, n * itemsize) 5446 */ 5447 __pyx_v_origsize = Py_SIZE(((PyObject *)__pyx_v_self)); 5448 5449 /* "array.pxd":151 5450 * cdef Py_ssize_t itemsize = self.ob_descr.itemsize 5451 * cdef Py_ssize_t origsize = Py_SIZE(self) 5452 * resize_smart(self, origsize + n) # <<<<<<<<<<<<<< 5453 * memcpy(self.data.as_chars + origsize * itemsize, stuff, n * itemsize) 5454 * return 0 5455 */ 5456 __pyx_t_1 = resize_smart(__pyx_v_self, (__pyx_v_origsize + __pyx_v_n)); if (unlikely(__pyx_t_1 == ((int)-1))) __PYX_ERR(1, 151, __pyx_L1_error) 5457 5458 /* "array.pxd":152 5459 * cdef Py_ssize_t origsize = Py_SIZE(self) 5460 * resize_smart(self, origsize + n) 5461 * memcpy(self.data.as_chars + origsize * itemsize, stuff, n * itemsize) # <<<<<<<<<<<<<< 5462 * return 0 5463 * 5464 */ 5465 (void)(memcpy((__pyx_v_self->data.as_chars + (__pyx_v_origsize * __pyx_v_itemsize)), __pyx_v_stuff, (__pyx_v_n * __pyx_v_itemsize))); 5466 5467 /* "array.pxd":153 5468 * resize_smart(self, origsize + n) 5469 * memcpy(self.data.as_chars + origsize * itemsize, stuff, n * itemsize) 5470 * return 0 # <<<<<<<<<<<<<< 5471 * 5472 * cdef inline int extend(array self, array other) except -1: 5473 */ 5474 __pyx_r = 0; 5475 goto __pyx_L0; 5476 5477 /* "array.pxd":145 5478 * return op 5479 * 5480 * cdef inline int extend_buffer(array self, char* stuff, Py_ssize_t n) except -1: # <<<<<<<<<<<<<< 5481 * """ efficient appending of new stuff of same type 5482 * (e.g. of same array type) 5483 */ 5484 5485 /* function exit code */ 5486 __pyx_L1_error:; 5487 __Pyx_AddTraceback("cpython.array.extend_buffer", __pyx_clineno, __pyx_lineno, __pyx_filename); 5488 __pyx_r = -1; 5489 __pyx_L0:; 5490 __Pyx_RefNannyFinishContext(); 5491 return __pyx_r; 5492 } After rebuilding glibc and python with -O1 -ggdb3 and nostrip this is the bottom of my stack: #0 0x3f4a1c4c in __GI_memcpy (dstpp=0x3ecb9dca, srcpp=0x3fffdc50, len=556480) at memcpy.c:52 __nwords = 139120 __nblocks = <optimized out> dstp = 1053544812 srcp = 1073745906 #1 0x3ee25258 in memcpy (__len=556482, __src=<optimized out>, __dest=<optimized out>) at /usr/include/bits/string_fortified.h:34 No locals. #2 __pyx_f_7cpython_5array_extend_buffer (__pyx_v_n=2, __pyx_v_stuff=<optimized out>, __pyx_v_self=0x3ee79460) at /var/tmp/portage/dev-python/cython-0.29.21-r1/work/cython-0.29.21/tests/run/pyarrayng.c:5465 __pyx_v_itemsize = <optimized out> __pyx_v_origsize = 2 __pyx_r = <optimized out> __pyx_t_1 = 0 __pyx_lineno = 0 __pyx_filename = 0x0 __pyx_clineno = 0 __pyx_v_itemsize = <optimized out> __pyx_v_origsize = <optimized out> __pyx_r = <optimized out> __pyx_t_1 = <optimized out> __pyx_lineno = <optimized out> __pyx_filename = <optimized out> __pyx_clineno = <optimized out> And asm context now from #0 0x3f4a1c24 <+80>: movew %pc@(0x3f4a1c2c <__GI_memcpy+88>,%d1:l),%d1 0x3f4a1c28 <+84>: jmp %pc@(0x3f4a1c2c <__GI_memcpy+88>,%d1:w) 0x3f4a1c2c <+88>: .short 0x003e 0x3f4a1c2e <+90>: orib #50,0x2c 0x3f4a1c34 <+96>: orib #32,%fp@- 0x3f4a1c38 <+100>: orib #20,%a2@+ 0x3f4a1c3c <+104>: movel %a1@,%a2@ 0x3f4a1c3e <+106>: subql #1,%d4 0x3f4a1c40 <+108>: movel %a1@(4),%a2@(4) 0x3f4a1c46 <+114>: movel %a1@(8),%a2@(8) => 0x3f4a1c4c <+120>: movel %a1@(12),%a2@(12) 0x3f4a1c52 <+126>: movel %a1@(16),%a2@(16) 0x3f4a1c58 <+132>: movel %a1@(20),%a2@(20) 0x3f4a1c5e <+138>: movel %a1@(24),%a2@(24) 0x3f4a1c64 <+144>: movel %a1@(28),%a2@(28) And poking some of those variables in memcpy: x 0x3ecb9dca 0x3ecb9dca: 0x00000185 x 0x3fffdc50 0x3fffdc50: 0x00000185 Stack level 0, frame at 0x3fffdc28: pc = 0x3f4a1c4c in __GI_memcpy (memcpy.c:52); saved pc = 0x3ee25258 called by frame at 0x3fffdc64 source language c. Arglist at 0x3fffdc0c, args: dstpp=0x3ecb9dca, srcpp=0x3fffdc50, len=556480 Locals at 0x3fffdc0c, Previous frame's sp is 0x3fffdc28 Saved registers: d2 at 0x3fffdc10, d3 at 0x3fffdc14, d4 at 0x3fffdc18, a2 at 0x3fffdc1c, a5 at 0x3fffdc20, pc at 0x3fffdc24 (gdb) info all-registers d0 0x87dc0 556480 d1 0x3e 62 d2 0x20 32 d3 0x3ecb9dcc 1053531596 d4 0x4250 16976 d5 0x3eed048c 1055720588 d6 0x3eebc238 1055638072 d7 0x3eebc22c 1055638060 a0 0x3ecb9dca 0x3ecb9dca a1 0x40000ff2 0x40000ff2 a2 0x3ecbd16c 0x3ecbd16c a3 0x7 0x7 a4 0x3ee7954c 0x3ee7954c a5 0x3ee40000 0x3ee40000 fp 0x3fffdc5c 0x3fffdc5c sp 0x3fffdc10 0x3fffdc10 ps 0x4 4 pc 0x3f4a1c4c 0x3f4a1c4c <__GI_memcpy+120> fp0 3 (raw 0x40000000c000000000000000) fp1 1602806335 (raw 0x401d0000bf11c47e00000000) fp2 nan(0xffffffffffffffff) (raw 0x7fff0000ffffffffffffffff) fp3 nan(0xffffffffffffffff) (raw 0x7fff0000ffffffffffffffff) fp4 nan(0xffffffffffffffff) (raw 0x7fff0000ffffffffffffffff) fp5 nan(0xffffffffffffffff) (raw 0x7fff0000ffffffffffffffff) fp6 nan(0xffffffffffffffff) (raw 0x7fff0000ffffffffffffffff) fp7 nan(0xffffffffffffffff) (raw 0x7fff0000ffffffffffffffff) fpcontrol 0x0 0 fpstatus 0x0 0 fpiaddr 0x0 0x0 Although I have seen various Python-related test failures on m68k, cryptography wasn't one of them. There was a bad bug in glibc that affected m68k for a while. I did tell Kent about it but I think that was after he filed this bug. It should all be fine now so closing. |