Python 3.14 crash randomly on AMD64 Debian root 3.14 buildbot: CPU bug

On AMD64 Debian root 3.14, on some builds, Python 3.14 does crash randomly.

For example, on build 1874, test_unicodedata failed with failed C assertion, but then passed when re-run in verbose mode

Build 1874: https://buildbot.python.org/#/builders/1742/builds/1874

test_failed_import_during_compiling (test.test_unicodedata.UnicodeMiscTest.test_failed_import_during_compiling) ... ok
test_linebreak_7643 (test.test_unicodedata.UnicodeMiscTest.test_linebreak_7643) ...

python: Python/generated_cases.c.h:8398: _PyEval_EvalFrameDefault: Assertion `oparg & 1' failed.
Fatal Python error: Aborted

Current thread 0x00007fa321491740 [python] (most recent call first):
  File "/root/buildarea/3.14.angelico-debian-amd64/build/Lib/unittest/case.py", line 905 in _getAssertEqualityFunc
  File "/root/buildarea/3.14.angelico-debian-amd64/build/Lib/unittest/case.py", line 924 in assertEqual
  File "/root/buildarea/3.14.angelico-debian-amd64/build/Lib/test/test_unicodedata.py", line 814 in test_linebreak_7643

Many tests failed once, but passed when re-run in verbose mode. Two tests failed twice:

    test.test_multiprocessing_spawn.test_processes test_collections
    test_math test_statistics test_unicodedata test_unparse
    test_userstring test_zipimport

2 tests failed:
    test_collections test_math

Python built with ./configure --prefix '$(PWD)/target' --with-pydebug on Debian GNU/Linux 12 (bookworm) using gcc -Og: gcc (Debian 12.2.0-14) 12.2.0.

Recent builds which failed:

https://buildbot.python.org/#/builders/1742/builds/1874 (8 re-run tests)
https://buildbot.python.org/#/builders/1742/builds/1870 (24 re-run tests)
https://buildbot.python.org/#/builders/1742/builds/1859 (3 re-run tests)
https://buildbot.python.org/#/builders/1742/builds/1858 (3 re-run tests)
https://buildbot.python.org/#/builders/1742/builds/1857 (5 re-run tests)
https://buildbot.python.org/#/builders/1742/builds/1844 (13 re-run tests)
https://buildbot.python.org/#/builders/1742/builds/1843 (9 re-run tests)
https://buildbot.python.org/#/builders/1742/builds/1841 (8 re-run tests)

I tried but failed to reproduce the issue in a Debian Bookworm (12) container with:

git clone https://github.com/python/cpython
cd cpython
git checkout 8e62b0898a28cdbc0bd80a97dbfef6036b4d5bcf  # build 1874
./configure --cache-file=../configure.cache --with-pydebug
make -j14
./python -m test -j0 test_codecmaps_cn test_http_cookies test_math test_ntpath test_statistics test_tokenize test_unicodedata test_unparse test_userstring

I tried other commits, but I still failed to reproduce the issue:

build 1844: d26fe798c7feac115067ad0e18177f1ef0a4c9b3
build 1870: 9cf9e3859dd98f1c3d127afd0b06465857505809

I built Python twice at each commit and I failed to reproduce the issue.

Example of script:

set -x -e
git clean -fdx
git checkout d26fe798c7feac115067ad0e18177f1ef0a4c9b3
./configure --cache-file=../configure.cache --with-pydebug
make -j14
./python -m test -j0 test_codecmaps_cn test_http_cookies test_math test_ntpath test_statistics test_tokenize test_unicodedata test_unparse test_userstring

Build 1876 is quite bad: https://buildbot.python.org/#/builders/1742/builds/1876

22 re-run tests:
    test.test_asyncio.test_base_events test.test_asyncio.test_sendfile
    test_ast test_buffer test_cext test_codecs test_context test_email
    test_gzip test_logging test_math test_pickle test_queue test_ssl
    test_statistics test_struct test_threading test_tokenize
    test_traceback test_unicodedata test_unparse test_zipimport

9 tests failed:
    test_ast test_email test_math test_pickle test_queue
    test_statistics test_tokenize test_traceback test_unparse

Examples of bugs:

0:02:01 load avg: 3.18 [ 71/537/3] test_traceback worker non-zero exit code (Exit code -6 (SIGABRT))
python: Python/generated_cases.c.h:9033: _PyEval_EvalFrameDefault: Assertion `_Py_IsImmortal(obj)' failed.
Fatal Python error: Aborted

Current thread 0x00007fc087003740 [python] (most recent call first):
  File "<frozen importlib._bootstrap>", line 311 in acquire
  File "<frozen importlib._bootstrap>", line 421 in __enter__
  File "<frozen importlib._bootstrap>", line 1368 in _find_and_load
  File "/root/buildarea/3.14.angelico-debian-amd64/build/Lib/ntpath.py", line 559 in <module>
  (...)

and

(...)
test_ints (test.test_pickle.PyPicklerTests.test_ints) ... ok
test_large_pickles (test.test_pickle.PyPicklerTests.test_large_pickles) ... ok
test_list_chunking (test.test_pickle.PyPicklerTests.test_list_chunking) ... python: Python/generated_cases.c.h:11686: _PyEval_EvalFrameDefault: Assertion `oparg >= 2' failed.
Fatal Python error: Aborted

Current thread 0x00007fb63f6a3740 [python] (most recent call first):
  File "/root/buildarea/3.14.angelico-debian-amd64/build/Lib/pickle.py", line 831 in save_long
  File "/root/buildarea/3.14.angelico-debian-amd64/build/Lib/pickle.py", line 572 in save
  File "/root/buildarea/3.14.angelico-debian-amd64/build/Lib/pickle.py", line 1023 in _batch_appends
  File "/root/buildarea/3.14.angelico-debian-amd64/build/Lib/pickle.py", line 1009 in save_list
  File "/root/buildarea/3.14.angelico-debian-amd64/build/Lib/pickle.py", line 572 in save
  File "/root/buildarea/3.14.angelico-debian-amd64/build/Lib/pickle.py", line 498 in dump
  File "/root/buildarea/3.14.angelico-debian-amd64/build/Lib/test/test_pickle.py", line 89 in dumps
  File "/root/buildarea/3.14.angelico-debian-amd64/build/Lib/test/pickletester.py", line 3403 in test_list_chunking
  File "/root/buildarea/3.14.angelico-debian-amd64/build/Lib/unittest/case.py", line 615 in _callTestMethod
  (...)

and

0:07:10 load avg: 3.71 [226/537/8] test_gzip worker non-zero exit code (Exit code -6 (SIGABRT)) -- running (1): test_statistics (30.1 sec)
python: Python/generated_cases.c.h:9130: _PyEval_EvalFrameDefault: Assertion `!PyStackRef_IsNull(GETLOCAL(oparg))' failed.
Fatal Python error: Aborted

Current thread 0x00007f475612d740 [python] (most recent call first):
  File "<frozen importlib._bootstrap_external>", line 133 in _path_join
  File "<frozen importlib._bootstrap_external>", line 1397 in find_spec
  File "<frozen importlib._bootstrap_external>", line 1270 in _get_spec
  File "<frozen importlib._bootstrap_external>", line 1296 in find_spec
  File "<frozen importlib._bootstrap>", line 1267 in _find_spec
  File "<frozen importlib._bootstrap>", line 1333 in _find_and_load_unlocked
  File "<frozen importlib._bootstrap>", line 1371 in _find_and_load
  File "/root/buildarea/3.14.angelico-debian-amd64/build/Lib/ssl.py", line 263 in <module>
  (...)

@Rosuav

I can't reproduce it either. Pinging @Rosuav

Hmm. I could simply reboot the VM and see if that clears it up, but before I do, is there any other sort of diagnosis that would be helpful?

@Rosuav

@Rosuav:

Hmm. I could simply reboot the VM and see if that clears it up, but before I do, is there any other sort of diagnosis that would be helpful?

So far, I don't have any clue about the root cause. I already saw such bug on your buildbot, maybe a few months ago (I didn't take any notes about it). So I'm not sure that a reboot is enough to work around the issue. The issue might come back after the reboot.

Can you get the version of the gcc package using dpkg -s gcc|grep ^Version? Also, can you upgrade Debian (sudo apt update && sudo apt upgrade) before rebooting, to check if a Debian upgrade is enough to fix the issue?

As I asked you by email, if it's possible, I would be interested to get a SSH access to this buildbot (virtual) machine to debug the issue.

If it's not possible, I'm curious to know if you're able to reproduce the issue on another Debian 12 machine?

7. Can you get the version of the gcc package using dpkg -s gcc|grep ^Version?

Version: 4:12.2.0-3

Though notably, the gcc-12 package has a version of 12.2.0-14, and the updates that I'm about to run will make that 12.2.0-14+deb12u1.

7. As I asked you by email, if it's possible, I would be interested to get a SSH access to this buildbot (virtual) machine to debug the issue.

Hmm, if this was recent, I didn't get that email. But yeah, that should be an option. I can create you an account on the VM, and then I'll give you a dedicated SSH port number for the buildbot. What username would you like?

Hmm, if this was recent, I didn't get that email. But yeah, that should be an option. I can create you an account on the VM, and then I'll give you a dedicated SSH port number for the buildbot. What username would you like?

I sent you an email today to the email address of your GitHub profile. I would like to use the username vstinner. You can get my SSH public from GitHub. You can send me the machine hostname or IP address by email (or here if it's not an issue to make it public).

We got in touch via email and credentials have been organized. (Also, while that was happening, I ran updates on the buildbot, although nothing particularly obvious went through.)

@Rosuav

Thanks to @Rosuav, I got access to the Debian 12 machine.

I built Python in 3 flavors:

pydebug: gcc -Og (./configure --with-pydebug)
release: gcc -O3 (./configure)
noopt: gcc -O0 -ggdb (./configure --with-pydebug 'CFLAGS=-O0 -ggdb')

So far, I only reproduced Python crashes on the "pydebug" build (gcc -Og). The failure rate is quite low. It's so low that I failed to compute it yet. I'm running stress tests in a loop and I only get a crash after 15 to 30 minutes (coarse estimation). One time, I got lucky and I got a crash after 29 runs, and then after 13 runs. But after than, I couldn't reproduce the crash for like 30 minutes.

I'm testing the same Python binary with a stress test which use the same random seed for all test worker processes. I would expect all processes to crash or all processes to pass the test, but no, instead I get random crashes. So it seems like it's a bug with the machine rather than a bug in Python.

I reproduced crashes in test_struct and test_buffer.

I like testing test_struct since the _struct extension is simple C code (ex: no syscall) and the test is quick (less than a second to run).

There are different "crashes":

python: Python/generated_cases.c.h:8353: _PyEval_EvalFrameDefault: Assertion 'oparg & 1' failed.
regular Python exception: AssertionError: 255 != 255 on self.assertEqual(x, retrieved) (not a "crash", just an exception)
python: ../Python/generated_cases.c.h:4546: _PyEval_EvalFrameDefault: Assertion 'oparg == 1' failed.
python: ../Python/generated_cases.c.h:8984: _PyEval_EvalFrameDefault: Assertion 'WITHIN_STACK_BOUNDS()' failed.

Note: time to time, I run ./python -m test -j0 test_codecmaps_cn test_http_cookies test_math test_ntpath test_statistics test_tokenize test_unicodedata test_unparse test_userstring test_struct test_ast test_buffer test_gzip test_logging test_codecs to try to reproduce crashes.

11. So far, I only reproduced Python crashes on the "pydebug" build (gcc -Og).

Ah! Then I shall attempt to build in debug mode on the host machine. Using ./python -m test -j0 -F test_struct as a stress test. Since it's able to run across ALL cores (rather than being capped at 2 inside the VM), this should mean that, if there's a hardware issue with one of the CPU cores, it's going to hit it.

My understanding of python -m test --help is that -F, since it implies --failfast, should halt the entire test if this crash occurs. Correct? If so, I will just leave it running here for a while and check back later. It's up to three minutes and 650ish tests run.

EDIT: No issues on the host machine. 0:37:42 load avg: 49.60 mem: 639.1 MiB [8385] test_struct passed and I hit Ctrl-C.

We've now had seven failures in a row and it's blocking 3.14 releases:

I just restarted the VM and it's now showing some greens. I have no idea still what is actually causing the issues.

Another bad build on AMD64 Debian root 3.14: https://buildbot.python.org/#/builders/1742/builds/1945

15 re-run tests:
    test.test_concurrent_futures.test_shutdown test_bytes test_io
    test_isinstance test_math test_modulefinder test_multibytecodec
    test_random test_statistics test_str test_tarfile test_traceback
    test_unicodedata test_unparse test_zipimport

When re-run in verbose mode, all tests passed, except of test.test_concurrent_futures.test_shutdown which failed again.

Logs:

0:01:44 load avg: 1.51 [ 73/538/2] test_random worker non-zero exit code (Exit code -6 (SIGABRT))
    test_binomialvariate (test.test_random.TestDistributions.test_binomialvariate) ...
    python: ./Include/internal/pycore_stackref.h:614: PyStackRef_DUP: Assertion `!PyStackRef_IsNull(ref)' failed.
    Fatal Python error: Aborted

0:04:29 load avg: 2.23 [145/538/3] test_bytes worker non-zero exit code (Exit code -6 (SIGABRT))
    test_find (test.test_bytes.ByteArrayAsStringTest.test_find) ...
    python: Python/generated_cases.c.h:1506: _PyEval_EvalFrameDefault: Assertion `0 && "Executing a cache."' failed.
    Fatal Python error: Aborted

0:04:35 load avg: 2.21 [147/538/4] test_str worker non-zero exit code (Exit code -6 (SIGABRT))
    test_isspace_invariant (test.test_str.StrTest.test_isspace_invariant) ...
    python: Python/generated_cases.c.h:5201: _PyEval_EvalFrameDefault: Assertion `oparg > 0' failed.
    Fatal Python error: Aborted

0:06:56 load avg: 1.79 [249/538/7] test_unparse worker non-zero exit code (Exit code -6 (SIGABRT))
    test_files (test.test_unparse.DirectoryTestCase.test_files) ...
    python: Python/generated_cases.c.h:1668: _PyEval_EvalFrameDefault: Assertion `WITHIN_STACK_BOUNDS()' failed.
    Fatal Python error: Aborted

0:09:24 load avg: 2.52 [289/538/9] test_statistics worker non-zero exit code (Exit code -11 (SIGSEGV))
    test_kde (test.test_statistics.TestKDE.test_kde) ...
    Fatal Python error: Segmentation fault

0:09:32 load avg: 2.40 [292/538/10] test_math worker non-zero exit code (Exit code -11 (SIGSEGV))
    test_sumprod_stress (test.test_math.MathTests.test_sumprod_stress) ...
    Fatal Python error: Segmentation fault

0:09:32 load avg: 2.40 [293/538/11] test_multibytecodec worker non-zero exit code (Exit code -6 (SIGABRT))
    test_bug1572832 (test.test_multibytecodec.Test_ISO2022.test_bug1572832) ...
    python: Python/generated_cases.c.h:9033: _PyEval_EvalFrameDefault: Assertion `_Py_IsImmortal(obj)' failed.
    Fatal Python error: Aborted

0:11:07 load avg: 6.49 [343/538/14] test_traceback worker non-zero exit code (Exit code -6 (SIGABRT))
    test_levenshtein_distance_short_circuit (test.test_traceback.MiscTest.test_levenshtein_distance_short_circuit) ...
    python: Python/generated_cases.c.h:8398: _PyEval_EvalFrameDefault: Assertion `oparg & 1' failed.
    Fatal Python error: Aborted

I tried to reproduce https://buildbot.python.org/#/builders/1742/builds/1945 failures on the 3.14 branch on the buildbot by running:

./python -m test -j2 --randseed=35745837 test.test_concurrent_futures.test_shutdown test_bytes test_io test_isinstance test_math test_modulefinder test_multibytecodec test_random test_statistics test_str test_tarfile test_traceback test_unicodedata test_unparse test_zipimport -F

After 10 minutes, test_io failed with a non-sense error: assertion_func must be a function, not an int

0:10:12 load avg: 1.86 [231/1] test_io failed (1 error)
test test_io failed -- Traceback (most recent call last):
  File "/home/vstinner/copy_cpython/Lib/test/test_io.py", line 2550, in test_writes_and_read1s
    self.check_writes(_read1)
    ~~~~~~~~~~~~~~~~~^^^^^^^^
  File "/home/vstinner/copy_cpython/Lib/test/test_io.py", line 1952, in check_writes
    self.assertEqual(bufio.write(contents[n:n+size]), size)
    ~~~~~~~~~~~~~~~~^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/home/vstinner/copy_cpython/Lib/unittest/case.py", line 925, in assertEqual
    assertion_func(first, second, msg=msg)
    ~~~~~~~~~~~~~~^^^^^^^^^^^^^^^^^^^^^^^^
TypeError: 'int' object is not callable

@vstinner

I think this might be registers.

I checked https://buildbot.python.org/#/builders/1742/builds/1945/steps/5/logs/stdio, L2673:

test_levenshtein_distance_short_circuit (test.test_traceback.MiscTest.test_levenshtein_distance_short_circuit) ... python: Python/generated_cases.c.h:8398: _PyEval_EvalFrameDefault: Assertion `oparg & 1' failed.

Then I built that commit with the same gcc (12.2.0-14+deb12u1) and -Og on my VM to see where oparg is stored.

$ gdb -batch -ex 'info line Python/generated_cases.c.h:8398' ./python
Line 8398 of "Python/generated_cases.c.h" starts at address 0x26bc75 <_PyEval_EvalFrameDefault+95266> and ends at 0x26bc7f <_PyEval_EvalFrameDefault+95276>.

$ gdb -batch -ex 'info scope _PyEval_EvalFrameDefault' ./python
...
Symbol oparg is multi-location:
  ...
  Range 0x26b6ee-0x26c450: a variable in $r13
  ...

$ objdump -d ./python --start-address=0x26bc75 --stop-address=0x26bc7f
  26bc75:	41 f6 c5 01          	test   $0x1,%r13b
  26bc79:	0f 84 89 00 00 00    	je     26bd08 <_PyEval_EvalFrameDefault+0x174b5>

I did the same objdump on the other builds:

3.14  -O0    2b5ea:  mov    -0x2c(%rbp),%eax
             2b5ed:  and    $0x1,%eax
3.14  -O3   18853:   testb  $0x1,-0x638(%rbp)
3.13  -Og   249c9e:  testb  $0x1,-0x130(%rbp)
3.15  -Og   2937d5:  testb  $0x1,-0x130(%rbp)
main  -Og   26fb96:  testb  $0x1,-0x130(%rbp)

That'd explain why 3.14 gets most of the failures with oparg sat in a register.

@vstinner Could you turn on core dumps on the VM (ulimit -c unlimited) and compare r13 against the bytecode in the core when it aborts?

@Rosuav

According to @Rosuav, this buildbot machine (Debian 12 VM) uses a CPU Intel 14700KF which can be affected by this hardware issue which causes random crashes: https://en.wikipedia.org/wiki/Raptor_Lake#Instability_and_degradation_issue.

Yesterday, I analyzed this assertion failure:

    0:33:12 load avg: 1.53 [752/1] test_io worker non-zero exit code (Exit code -6 (SIGABRT))
    python: Python/generated_cases.c.h:9033: _PyEval_EvalFrameDefault: Assertion `_Py_IsImmortal(obj)' failed.
    Fatal Python error: Aborted

The bug occurred in the _pyio Python module:

    (gdb) py-bt
    Traceback (most recent call first):
      File "/home/vstinner/copy_cpython/Lib/_pyio.py", line 1284, in _flush_unlocked
        while self._write_buf:
      File "/home/vstinner/copy_cpython/Lib/_pyio.py", line 1259, in write
        self._flush_unlocked()
      File "/home/vstinner/copy_cpython/Lib/test/test_io.py", line 1952, in check_writes
        self.assertEqual(bufio.write(contents[n:n+size]), size)
      File "/home/vstinner/copy_cpython/Lib/test/test_io.py", line 1962, in test_writes_and_flushes
        self.check_writes(lambda bufio: bufio.flush())

The LOAD_CONST 2 (None) was replaced with LOAD_CONST_IMMORTAL 2 (None) by the bytecode specializer. If I inspect the bytecode, I see LOAD_CONST_IMMORTAL opcode (190) with argument 2 (the None constant):

    (gdb) p next_instr[-1]
    $27 = {cache = 702, op = {code = 190 '\276', arg = 2 '\002'}, counter = {value_and_backoff = 702}}

The problem is that the opcode 2 became 0. The opcode variable lives in the $r13 register:

    (gdb) p oparg
    $28 = 0
    (gdb) info address oparg
    Symbol "oparg" is multi-location:
      Range 0x56455482db91-0x56455482dc1c: a variable in $r13
      (...)
    (gdb) p $r13
    $12 = 0

The code constant number 2 is the immortal None constant, whereas the constant number 0 is a string which is mortal:

    (gdb) p *((PyTupleObject*)((PyCodeObject*)(frame->f_executable.bits & ~3))->co_consts)->ob_item[0]
    $29 = {{ob_refcnt_full = 2, {ob_refcnt = 2, ob_overflow = 0, ob_flags = 0}}, ob_type = 0x564554bd7640 <PyUnicode_Type>}
    (gdb) p *((PyTupleObject*)((PyCodeObject*)(frame->f_executable.bits & ~3))->co_consts)->ob_item[2]
    $30 = {{ob_refcnt_full = 1407378104778752, {ob_refcnt = 3221225472, ob_overflow = 0, ob_flags = 5}}, ob_type = 0x564554bcd080 <_PyNone_Type>}
    (gdb) p ((PyTupleObject*)((PyCodeObject*)(frame->f_executable.bits & ~3))->co_consts)->ob_item[0]
    $31 = 'flush on closed file'
    (gdb) p ((PyTupleObject*)((PyCodeObject*)(frame->f_executable.bits & ~3))->co_consts)->ob_item[2]
    $32 = None

Assertion _Py_IsImmortal(obj) failed because the opcode 2 became 0 and the constant number 0 is not immortal.

@NekoAsakura:

I think this might be registers.

I confirm that I saw the CPU register $r13 value changed whereas its value should not change: it's a CPU bug.

@Rosuav

Uh oh. @Rosuav could you try pinning the VM to E-cores and see if the crashes stop? Hope it's just one core tricking 🎃.

24. Uh oh. @Rosuav could you try pinning the VM to E-cores and see if the crashes stop?

Hmm. I tried pinning the VBoxHeadless process to cores 25 and 26 (taskset -p 0x6000000 5344 where 5344 happens to be its current pid) but I'm not sure that it's respecting that. I set the VM to busywait for a while, and CPU 9 was the one that got busy. Changed the affinity mask, did it again; still CPU 9 (one of the highest performing cores) was the busy one. :(

taskset -p 0x6000000 5344

You might need -a as vCPUs have their own threads.

26. > taskset -p 0x6000000 5344
 You might need `-a` as vCPUs have their own threads.

Oh! Thank you. (Sorry, I probably come across as a pretty ignorant sysadmin, but I have never before needed to concern myself with which CPU core does what - which is broadly a good thing, I've never had a CPU with this sort of bug...) I was also off by one in my CPU numbering so I've now successfully set the affinity where I want it.

The build is now running and I'll check back in a bit. Two green lines on the CPU graph.

Total duration: 2 hour 8 min. Total tests: run=283,011 skipped=14,094. Result: INTERRUPTED. I'm going to call this good enough, and let a couple of real tests go through.

btw #142973 could be an early signal of this same issue?

Looks like it really was just one core. 106 builds since the pin without a crash, and the warnings are mostly #160986 (with open PR #161073), so closing.

Navigation Menu

Repository navigation

Python 3.14 crash randomly on AMD64 Debian root 3.14 buildbot: CPU bug #159764

3 remaining items

Metadata

Assignees

Labels

Projects

Milestone

Relationships

Development

Python 3.14 crash randomly on AMD64 Debian root 3.14 buildbot: CPU bug #159764

Description

Activity

vstinner commented on Oct 19, 2026

vstinner commented on Oct 19, 2026

vstinner commented on Oct 19, 2026

NekoAsakura commented on Oct 20, 2026

Rosuav commented on Oct 20, 2026

vstinner commented on Oct 20, 2026

Rosuav commented on Oct 20, 2026

vstinner commented on Oct 20, 2026

Rosuav commented on Oct 20, 2026

vstinner commented on Oct 20, 2026

Rosuav commented on Oct 20, 2026

hugovk commented on Oct 25, 2026

Rosuav commented on Oct 25, 2026

3 remaining items

vstinner commented on Oct 27, 2026

vstinner commented on Oct 28, 2026

NekoAsakura commented on Oct 28, 2026

vstinner commented on Oct 28, 2026

NekoAsakura commented on Oct 28, 2026

Rosuav commented on Oct 28, 2026

NekoAsakura commented on Oct 28, 2026

Rosuav commented on Oct 28, 2026

Rosuav commented on Oct 28, 2026

hugovk commented on Oct 29, 2026

NekoAsakura commented on Nov 2, 2026

Metadata

Metadata

Assignees

Labels

Projects

Milestone

Relationships

Development

Issue actions