Control: reopen -1 Control: forwarded -1 https://jira.mariadb.org/browse/MDEV-30572
The upstream fix https://github.com/MariaDB/server/pull/2482 was backported via https://salsa.debian.org/mariadb-team/mariadb-server/-/commit/7ac10dee3b961cf69b330de23df5f8554450783e to latest Debian build. However, now the test suite fails to start at all in https://buildd.debian.org/status/fetch.php?pkg=mariadb&arch=hppa&ver=1%3A10.11.1-4&stamp=1676007600&raw=0 ``` MariaDB Version 10.11.1-MariaDB-4 - SSL connections supported Using suites: main Collecting tests... Installing system database... - found 'core' (0/5) Core generated by '/<<PKGBUILDDIR>>/builddir/sql/mariadbd' Output from gdb follows. The first stack trace is from the failing thread. The following stack traces are from all threads (so the failing one is duplicated). -------------------------- warning: Can't open file anon_inode:[io_uring] which was expanded to anon_inode:[io_uring] during file-backed mapping note processing warning: Can't open file anon_inode:[io_uring] which was expanded to anon_inode:[io_uring] during file-backed mapping note processing [New LWP 31431] [New LWP 31427] [New LWP 31429] [New LWP 31428] [New LWP 31430] [Thread debugging using libthread_db enabled] Using host libthread_db library "/lib/hppa-linux-gnu/libthread_db.so.1". Core was generated by `/<<PKGBUILDDIR>>/builddir/sql/mariadbd --no-defaults --dis'. Program terminated with signal SIGABRT, Aborted. #0 0x43469c84 in my_register_filename (fd=1137958840, FileName=0x6 <error: Cannot access memory at address 0x6>, type_of_file=3646115528, error_message_number=<optimized out>, MyFlags=<optimized out>) at ./mysys/my_open.c:140 140 ./mysys/my_open.c: No such file or directory. [Current thread is 1 (Thread 0xd9d34380 (LWP 31431))] #0 0x43469c84 in my_register_filename (fd=1137958840, FileName=0x6 <error: Cannot access memory at address 0x6>, type_of_file=3646115528, error_message_number=<optimized out>, MyFlags=<optimized out>) at ./mysys/my_open.c:140 Backtrace stopped: Cannot access memory at address 0x7ab3 ``` The same upload also had other patches, so what we are seeing might be due to something else as well. Thus re-opening this bug and I see upstream Jira also remains open. Contributions from HPPA-experts welcome!