|
Unfortunately, the mariadb-stacktrace.log is useless for any analysis, because the addresses were resolved incorrectly. With a correctly resolved stack trace (possibly from a core dump), it would be possible to identify which type of a page was corrupted. With the available information, I cannot know if it was an undo log page or an index page, and therefore I cannot give suggestions how to recover the rest of the data.
There is no magic fix. The intended purpose of innodb_force_recovery is to allow you to dump the data. The option innodb_force_recovery=6 is the most dangerous one, because it will cause the redo log to be ignored altogether. Starting with 10.5 (thanks to MDEV-19514 removing the special meaning of innodb_force_recovery=4), it should be the only option that can corrupt the data further.
If you have a copy of the data directory as it was before attempting innodb_force_recovery=6, then I would suggest that you attempt to invoke the server in a debugger. Because it is crashing at startup, this should be fairly easy. See also https://mariadb.com/kb/en/how-to-produce-a-full-stack-trace-for-mysqld/ for some hints.
| 
mariadb-stacktrace.log