Pi3B+ illegal instruction in python3 STUR

Mine isn't a 3B+ so the following may be of no use ...

andy@raspberrypi:~ $ dmesg | grep -i machine [ 0.000000] Machine model: Raspberry Pi 3 Model B Rev 1.2

andy@raspberrypi:~ $ uname -a Linux raspberrypi 5.15.61-v8+ #1579 SMP PREEMPT Fri Aug 26 11:16:44 BST

andy@raspberrypi:~ $ python3 -V Python 3.9.2

Are you running just the 64 bit kernel or the 64 bit userland too? If it's the latter I don't recommend that with only 1GB of memory.

I'm only running full 64 bit Bookworm on Pi 4s and 5s, and there are no Python issues on those.

---druck

richard@chulka:~ $ cat /proc/cpuinfo [...] Revision : a02082 Serial : 0000000068bf39e8 Model : Raspberry Pi 3 Model B Rev 1.2

richard@chulka:~ $ uname -a Linux chulka 6.1.0-rpi8-rpi-v8 #1 SMP PREEMPT Debian 1:6.1.73-1+rpt1 (2024-01-25) aarch64 GNU/Linux

richard@chulka:~ $ dpkg -l linux-image-* python3-minimal libpython3.11 libc6 Desired=Unknown/Install/Remove/Purge/Hold | Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend |/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad) ||/ Name Version Architecture Description +++-=============================-===================-============-=============================================================== ii libc6:arm64 2.36-9+rpt2+deb12u4 arm64 GNU C Library: Shared libraries ii libpython3.11:arm64 3.11.2-6 arm64 Shared Python runtime library (version 3.11) ii linux-image-6.1.0-rpi7-rpi-v8 1:6.1.63-1+rpt1 arm64 Linux 6.1 for Raspberry Pi v8, Raspberry Pi ii linux-image-6.1.0-rpi8-rpi-v8 1:6.1.73-1+rpt1 arm64 Linux 6.1 for Raspberry Pi v8, Raspberry Pi ii linux-image-rpi-v8 1:6.1.73-1+rpt1 arm64 Linux for Raspberry Pi v8 (meta-package) ii python3-minimal 3.11.2-1+b1 arm64 minimal subset of the Python language (default python3 version)

richard@chulka:~ $ file -L /usr/bin/python3 /usr/bin/python3: ELF 64-bit LSB executable, ARM aarch64, version 1 (SYSV), dynamically linked, interpreter /lib/ld-linux-aarch64.so.1, BuildID[sha1]=15a1b7b17a3e246ca60bac3646ced99af27ca711, for GNU/Linux 3.7.0, stripped

richard@chulka:~ $ sha256sum /usr/bin/python3 37e79c476a2b3feb191fb4af8012363bbde2461fce10418a569bed0765f86e95 /usr/bin/python3

richard@chulka:~ $ python3 Python 3.11.2 (main, Mar 13 2023, 12:18:29) [GCC 12.2.0] on linux Type "help", "copyright", "credits" or "license" for more information. >>>

However there is an inconsistency with the material in the bug report. Stefano quotes a STUR insn but if I disassemble it I get LDP at that location:

richard@chulka:~ $ gdb /usr/bin/python3 junk/python3_core_dump.34704 [..] Reading symbols from /usr/bin/python3... Reading symbols from /usr/lib/debug/.build-id/15/a1b7b17a3e246ca60bac3646ced99af27ca711.debug... [New LWP 34704]

warning: Build-id of /lib/aarch64-linux-gnu/libm.so.6 does not match core file.

warning: Build-id of /lib/aarch64-linux-gnu/libc.so.6 does not match core file.

warning: Build-id of /lib/ld-linux-aarch64.so.1 does not match core file. [Thread debugging using libthread_db enabled] Using host libthread_db library "/lib/aarch64-linux-gnu/libthread_db.so.1". Core was generated by `python3'. Program terminated with signal SIGILL, Illegal instruction. #0 0x0000000000510d48 in _PyObject_GC_UNTRACK (op=<optimized out>) at ../Include/internal/pycore_object.h:169 169 ../Include/internal/pycore_object.h: No such file or directory. (gdb) disassemble 0x0000000000510d48 Dump of assembler code for function gen_dealloc: 0x0000000000510d40 <+0>: stp x29, x30, [sp, #-96]! 0x0000000000510d44 <+4>: mov x29, sp => 0x0000000000510d48 <+8>: ldp x3, x2, [x0, #-16] 0x0000000000510d4c <+12>: stp x19, x20, [sp, #16]

This could reflect the libc-level differences, but gen_dealloc is part of the Python implementation, not the C library.

All the packages are arm64.

I am aware that they need more RAM, but does that create such errors?

It doesn't, you've got some configuration problem that will probably only be installed by a reinstall. If you are going down that route I'm suggesting that for machines which only have 1GB and function worse with a 64 bit OS and programs, you reinstall a 32 bit OS.

---druck

Just a wild guess on my part, but in theory if the program in question called malloc() and neglected to check whether the result was NULL, lack of RAM could be a contributing factor to a number of segmentation faults or similar. There might be a scenario where it could end up in an illegal instruction fault.