Новогодний детектив: странный хайзенбаг в «питоньих» часах

это не воспроизводится пока нигде кроме конкретной виртуалки товарища, сообщившего об ошибке.

После прочтения этой строки сразу возникает вопрос: битая память?

Может миграция виртуалки с одного хоста на другой, с другим CPU другой частоты? Там могут быть засады с коррекцией точного времени

Склонируйте или мигрируйте виртуалку на другой хост -- проблема сохраняется?
Если да, то проверьте пакетным менеджером, что CRC всех файлов правильные.

Возможно, что-то не так при работе с FPU в QEMU (сохранение и восстановление состояния при уходе в гипервизор и обратно). Возможно, что нужен дебаг на стороне хостовой системы.

Вам это удалось воспроизвести где-то ещё? Пример скрипта для воспроизведения есть? Я думаю, надо просить общественность пробовать на разных машинах, пока не найдётся закономерность.

Клонировать виртуалку на другой хост. Искать отличия виртуалки от стандартных либ. Поставить рядом другие сборки питона этой и соседних версий.

Наверняка какой-нибудь локальный глюк типа подбитого из-за сбоя железа *.pyc (ну а вдруг?) или какой-то либы. Вангую, что шансы на баг в дистрибутивном софте исчезающе малы.

Хм, забавно... На некоторых моих виртуалках с fail2ban`ом периодически проскакивали строчки в логах с руганью на возможно некорректно установленную тайм-зону. Естественно, TZ были настроены нормально. Всё перерыл, ничего не нашёл, плюнул и забил. Возможно, это как раз был вышеописанный глюк.

И, да, проблема вряд ли в железе - везде ECC во все щели.

У меня есть ноутбук, на котором операции с float-ами время от времени возвращают NaN без явной причины. Софт, на котором я это обнаружил — смесь питона с Си, и изучал я эту проблему довольно давно (лет 10 назад), так что уже не помню, проявлялась проблема в питоньем коде или в сишном...

Всё ждал когда же упомянут monkeypatching или какие-то модули, закрывающие собой стандартные, но не дождался.

комп: win7 64x
py (3.8.10 64x):
Z:\_py\_новогодний_детектив>py
Python 3.8.10 (tags/v3.8.10:3d8993a, May  3 2021, 11:48:03) [MSC v.1928 64 bit (AMD64)] on wi
n32
время:
(сейчас 2021-12-31 T 21:07:41)
-------------------------------
py -c "import time; print(time.strftime('%Y-%m-%dT%H:%M:%S', time.gmtime(1705034426)))"

Z:\_py\_новогодний_детектив>py -c "import time; print(time.strftime('%Y-%m-%dT%H:%M:%S', time
2024-01-12T04:40:26

Z:\_py\_новогодний_детектив>py -c "import time; print(time.strftime('%Y-%m-%dT%H:%M:%S', time
2024-01-12T04:40:26

Z:\_py\_новогодний_детектив>py -c "import time; print(time.strftime('%Y-%m-%dT%H:%M:%S', time
2024-01-12T04:40:26

(сейчас 2021-12-31 T 21:07:41)
==========

py -c "import time; print(time.strftime('%Y-%m-%d T %H:%M:%S', time.localtime(1705034426)))"

Z:\_py\_новогодний_детектив>py -c "import time; print(time.strftime('%Y-%m-%d T %H:%M:%S', ti
2024-01-12 T 06:40:26

Z:\_py\_новогодний_детектив>py -c "import time; print(time.strftime('%Y-%m-%d T %H:%M:%S', ti
2024-01-12 T 06:40:26

Z:\_py\_новогодний_детектив>py -c "import time; print(time.strftime('%Y-%m-%d T %H:%M:%S', ti
2024-01-12 T 06:40:26

Ошибка в одном в 26 бите, значение ошибки приблизительно равно одному из числу в степени двойки

Я бы предложил попытаться разделить програмная это или аппаратная ошибка. Для этого можно создать легковесную копию при помощи того же lxc/lxd/chroot/docker/whatever.

mkdir /opt/lxc-data


rsync --exclude=/dev \
  --exclude=/home \
  --exclude=/mnt \
  --exclude=/opt/lxc-data \
  --exclude=/proc \
  --exclude=/root \
  --exclude=/run \
  --exclude=/sys \
  --exclude=/tmp \
  --exclude=/snap \
  --exclude=/var/log \
  -av / /opt/lxc-data

apt install lxc

lxc-create lxc --template=none

cd /var/lib/lxc/lxc

mv /opt/lxc-data rootfs

# Distribution configuration
lxc.include = /usr/share/lxc/config/common.conf
lxc.apparmor.profile = unconfined
lxc.cgroup.devices.allow = a


lxc.tty.dir = lxc

lxc.pty.max = 1024

lxc.tty.max = 4

lxc.hook.clone = /usr/share/lxc/hooks/clonehostname

lxc.mount.auto = cgroup:mixed proc:mixed sys:mixed
lxc.mount.entry = /sys/fs/fuse/connections sys/fs/fuse/connections none bind,optional 0 0

# For Ubuntu 14.04
lxc.mount.entry = /sys/kernel/debug sys/kernel/debug none bind,optional 0 0
lxc.mount.entry = /sys/kernel/security sys/kernel/security none bind,optional 0 0
lxc.mount.entry = /sys/fs/pstore sys/fs/pstore none bind,optional 0 0
lxc.mount.entry = mqueue dev/mqueue mqueue rw,relatime,create=dir,optional 0 0
lxc.arch = linux64

# Container specific configuration
lxc.rootfs.path = dir:/var/lib/lxc/lxc/rootfs
lxc.uts.name = lxc

lxc-start -d lxc

lxc-attach lxc

...
lxc-stop lxc

Причем поднимать копию по идее можно на той же машине, чтобы избавиться от copy on write. И так можно сделать легковесный контейнер с минимально необходимыми данными для воспроизведения

Я бы проверил память для начала, вполне возможно что это какой нибудь row hammer в дефектной памяти.

Переустановка Debian 11 а затем Fedora 34 на той же VM с последующим тестом на чистых системах ничего не поменяли - тем самым подозрение на hypervisor/hardware проблемы усилилось.

Честно погонял однострочник сначала на серваке (Fedora35, python3 v3.10.1), потом на виртуалке (KVM, Alma Linux 8.5, python 3.6.8). И ничего интересного - честно досчитало до победного конца.

Может нужна именно конкретная версия питона, а может, действительно, нужна очень конкретная машина, где это всё запускается :)

Вышла вторая часть "детектива".