Package: pypy Version: 7.2.0~rc0+dfsg-1 Severity: normal User: debian-...@lists.debian.org Usertags: armhf Control: affects -1 pypy3
Observable since 7.2.0~rc0+dfsg-1 we've seen occasional SIGILLs and SEGV with pypy's armhf build running on Armada XP boards (arnold, hoiby, hartmann, henze). https://buildd.debian.org/status/logs.php?pkg=pypy&arch=armhf e.g. https://buildd.debian.org/status/fetch.php?pkg=pypy&arch=armhf&ver=7.2.0%7Erc0%2Bdfsg-1&stamp=1570119992&raw=0 Reproduces at least 50% of the time on abel, the Armada XP porterbox. This was an attempt to build pypy3 7.3.4~rc1+dfsg-1 with pypy 7.3.3+dfsg-1. Core was generated by `pypy --jit loop_longevity=300 -u /home/stefanor/pypy3-7.3.4~rc1+dfsg/rpython/bi'. Program terminated with signal SIGILL, Illegal instruction. #0 0xb03fe3e0 in ?? () (gdb) bt #0 0xb03fe3e0 in ?? () #1 0xb65f914c in ?? () from /usr/lib/pypy/bin/libpypy-c.so Backtrace stopped: previous frame identical to this frame (corrupt stack?) (gdb) info threads Id Target Id Frame * 1 Thread 0xb6f8e010 (LWP 16596) 0xb03fe3e0 in ?? () (gdb) disas No function contains program counter for selected frame. (gdb) info registers r0 0xb486f5bc 3028743612 r1 0x9 9 r2 0xb473a710 3027478288 r3 0xb66052ec 3059765996 r4 0x1e5ea00 31844864 r5 0xb486f6d4 3028743892 r6 0x0 0 r7 0xb486f714 3028743956 r8 0xb4750060 3027566688 r9 0xb486f6e4 3028743908 r10 0x1f31650 32708176 r11 0xb486f714 3028743956 r12 0x108 264 sp 0xbe91c748 0xbe91c748 lr 0xb65f914c -1235250868 pc 0xb03fe3e0 0xb03fe3e0 cpsr 0xa0070010 -1610153968 fpscr 0x8000001d -2147483619 (gdb) disas 0xb03fe3d0,+32 Dump of assembler code from 0xb03fe3d0 to 0xb03fe3f0: 0xb03fe3d0: bne 0xb03fe668 0xb03fe3d4: ldr r2, [pc, #-248] ; 0xb03fe2e4 0xb03fe3d8: ldr r2, [r2, #8] 0xb03fe3dc: cmp r2, #0 => 0xb03fe3e0: beq 0xb03fe688 0xb03fe3e4: ldr r2, [pc, #-256] ; 0xb03fe2ec 0xb03fe3e8: ldr r2, [r2, #8] 0xb03fe3ec: cmp r2, #0 End of assembler dump. (gdb) x/32 0xb03fe3d0 0xb03fe3d0: 0x1a0000a4 0xe51f20f8 0xe5922008 0xe3520000 0xb03fe3e0: 0x0a0000a8 0xe51f2100 0xe5922008 0xe3520000 0xb03fe3f0: 0x0a0000ac 0xe51f2108 0xe1520003 0x1a0000b1 0xb03fe400: 0xe300c114 0xe79b200c 0xe592400c 0xe594c004 0xb03fe410: 0xe30be4d8 0xe34be661 0xe15c000e 0x1a0000b1 0xb03fe420: 0xe5924008 0xe5949004 0xe2897001 0xe5946008 0xb03fe430: 0xe5966004 0xe1560007 0xe300c10c 0xe78b400c 0xb03fe440: 0xe30d42dd 0xe34b4535 0xe300c10c 0xe79b000c (gdb) disas 0xb03fe688,+32 Dump of assembler code from 0xb03fe688 to 0xb03fe6a8: 0xb03fe688: ldr r12, [pc, #-936] ; 0xb03fe2e8 0xb03fe68c: push {r12} ; (str r12, [sp, #-4]!) 0xb03fe690: movw r12, #57916 ; 0xe23c 0xb03fe694: movt r12, #45119 ; 0xb03f 0xb03fe698: push {r12} ; (str r12, [sp, #-4]!) 0xb03fe69c: movw r12, #0 0xb03fe6a0: movt r12, #45057 ; 0xb001 0xb03fe6a4: blx r12 End of assembler dump. Seems like this is probably an issue with flushing the I-cache after generating jit-code, but as far as I can see, pypy is doing the right thing, calling __clear_cache after writing jit-code: https://foss.heptapod.net/pypy/pypy/-/blob/release-pypy2.7-v7.3.4rc1/rpython/jit/backend/arm/codebuilder.py#L458 SR
