Arch Linux

Akonadi 20.11.80 crashed after few hours and every start trying to fix the corrupt DB results in instant crash of mariaDB 10.5.8. No recovery mode (1-3) works.

Start
```
akonadictl start
org.kde.pim.akonadictl: Starting Akonadi Server...
org.kde.pim.akonadictl: done.
Connecting to deprecated signal QDBusConnectionInterface::serviceOwnerChanged(QString,QString,QString)
org.kde.pim.akonadiserver: Starting up the Akonadi Server...
org.kde.pim.akonadiserver: database server stopped unexpectedly
org.kde.pim.akonadiserver: Database process exited unexpectedly during initial connection!
org.kde.pim.akonadiserver: executable: "/usr/bin/mysqld"
org.kde.pim.akonadiserver: arguments: ("--defaults-file=/home/user/.local/share/akonadi/mysql.conf", "--datadir=/home/user/.local/share/akonadi/db_data/", "--socket=/run/user/1000/akonadi/mysql.socket", "--pid-file=/run/user/1000/akonadi/mysql.pid")
org.kde.pim.akonadiserver: stdout: ""
org.kde.pim.akonadiserver: stderr: "2020-11-20 4:31:10 0 [Note] /usr/bin/mysqld (mysqld 10.5.8-MariaDB) starting as process 36543 ...\n"
org.kde.pim.akonadiserver: exit code: 6
org.kde.pim.akonadiserver: process error: "Process crashed"
org.kde.pim.akonadiserver: Shutting down AkonadiServer...
org.kde.pim.akonadicontrol: Application '/usr/bin/akonadiserver' exited normally...

```

gdb start
```
gdb --args /usr/bin/mysqld --defaults-file=/home/user/.local/share/akonadi/mysql.conf --datadir=/home/user/.local/share/akonadi/db_data/ --socket=/run/user/1000/akonadi/mysql.socket --pid-file=/run/user/1000/akonadi/mysql.pid

(gdb) run
Starting program: /usr/bin/mysqld --defaults-file=/home/user/.local/share/akonadi/mysql.conf --datadir=/home/user/.local/share/akonadi/db_data/ --socket=/run/user/1000/akonadi/mysql.socket --pid-file=/run/user/1000/akonadi/mysql.pid
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/usr/lib/libthread_db.so.1".
2020-11-20 7:27:48 0 [Note] /usr/bin/mysqld (mysqld 10.5.8-MariaDB) starting as process 68482 ...
[New Thread 0x7ffff7fc9640 (LWP 68486)]
[New Thread 0x7ffff6b12640 (LWP 68487)]
[New Thread 0x7ffff5f10640 (LWP 68488)]
[New Thread 0x7ffff530f640 (LWP 68489)]

Thread 1 "mysqld" received signal SIGABRT, Aborted.
```

MariaDB log
```
0 [Warning] option 'innodb-purge-threads': unsigned value 0 adjusted to 1
0 [Note] InnoDB: Using Linux native AIO
0 [Note] InnoDB: Uses event mutexes
0 [Note] InnoDB: Compressed tables use zlib 1.2.11
0 [Note] InnoDB: Number of pools: 1
0 [Note] InnoDB: Using crc32 + pclmulqdq instructions
0 [Note] mysqld: O_TMPFILE is not supported on /tmp (disabling future attempts)
0 [Note] InnoDB: Initializing buffer pool, total size = 134217728, chunk size = 134217728
0 [Note] InnoDB: Completed initialization of buffer pool
0 [Note] InnoDB: If the mysqld execution user is authorized, page cleaner thread priority can be changed. See the man page of setpriority().
0 [Note] InnoDB: Starting crash recovery from checkpoint LSN=2372408844,2372408844
0 [Warning] InnoDB: Ignoring a doublewrite copy of page [page id: space=0, page number=314] with future log sequence number 2384902644
.....
0 [Warning] InnoDB: Ignoring a doublewrite copy of page [page id: space=39, page number=108] with future log sequence number 2384905821
0 [ERROR] InnoDB: Page [page id: space=0, page number=2] log sequence number 2380969335 is in the future! Current system log sequence number 2372492099.
0 [ERROR] InnoDB: Your database may be corrupt or you may have copied the InnoDB tablespace but not the InnoDB log files. Please refer to https://mariadb.com/kb/en/library/innodb-recovery-modes/ for information about forcing recovery.
0 [ERROR] InnoDB: Page [page id: space=0, page number=4] log sequence number 2376489968 is in the future! Current system log sequence number 2372492099.
0 [ERROR] InnoDB: Your database may be corrupt or you may have copied the InnoDB tablespace but not the InnoDB log files. Please refer to https://mariadb.com/kb/en/library/innodb-recovery-modes/ for information about forcing recovery.
.....
0 [ERROR] InnoDB: Page [page id: space=0, page number=207] log sequence number 2384842345 is in the future! Current system log sequence number 2372492099.
0 [ERROR] InnoDB: Your database may be corrupt or you may have copied the InnoDB tablespace but not the InnoDB log files. Please refer to https://mariadb.com/kb/en/library/innodb-recovery-modes/ for information about forcing recovery.
0x7f4bc5171800 InnoDB: Assertion failure in file /build/mariadb/src/mariadb-10.5.8/storage/innobase/include/fut0lst.h line 127
InnoDB: Failing assertion: addr.page == FIL_NULL || addr.boffset >= FIL_PAGE_DATA
InnoDB: We intentionally generate a memory trap.
InnoDB: Submit a detailed bug report to https://jira.mariadb.org/
InnoDB: If you get repeated assertion failures or crashes, even
InnoDB: immediately after the mysqld startup, there may be
InnoDB: corruption in the InnoDB tablespace. Please refer to
InnoDB: https://mariadb.com/kb/en/library/innodb-recovery-modes/
InnoDB: about forcing recovery.
[ERROR] mysqld got signal 6 ;
This could be because you hit a bug. It is also possible that this binary
or one of the libraries it was linked against is corrupt, improperly built,
or misconfigured. This error can also be caused by malfunctioning hardware.

To report this bug, see https://mariadb.com/kb/en/reporting-bugs

We will try our best to scrape up some info that will hopefully help
diagnose the problem, but since we have already crashed,
something is definitely wrong and this may fail.

Server version: 10.5.8-MariaDB
key_buffer_size=16384
read_buffer_size=131072
max_used_connections=0
max_threads=258
thread_count=0
It is possible that mysqld could use up to
key_buffer_size + (read_buffer_size + sort_buffer_size)*max_threads = 567951 K bytes of memory
Hope that's ok; if not, decrease some variables in the equation.

Thread pointer: 0x0
Attempting backtrace. You can use the following information to find out
where mysqld died. If you see no messages after this, something went
terribly wrong...
stack_bottom = 0x0 thread_stack 0x49000
??:0(my_print_stacktrace)[0x558a7a903bff]
??:0(handle_fatal_signal)[0x558a7a3e9d90]
sigaction.c:0(__restore_rt)[0x7f4bc58bf0f0]
:0(__GI_raise)[0x7f4bc53da615]
:0(__GI_abort)[0x7f4bc53c3862]
??:0(Wsrep_server_service::log_dummy_write_set(wsrep::client_state&, wsrep::ws_meta const&))[0x558a7a0ca414]
??:0(Wsrep_server_service::log_dummy_write_set(wsrep::client_state&, wsrep::ws_meta const&))[0x558a7a0c9eff]
??:0(Wsrep_server_service::log_dummy_write_set(wsrep::client_state&, wsrep::ws_meta const&))[0x558a7a0ca177]
```