Mariadb – MySQL service will not start [ERROR] thesqld got exception 0xc0000005

mariadb

Server was running just fine with MariaDB 10.3.13. Stopped the service, installed MariaDB 10.3.16 and restarted the server just fine. Stopped the service again and installed MariaDB 10.4.6 and the service will no longer start.

Backing off to 10.3.16 or 10.3.13 does not change the problem. I have tried using the innodb_force_recovery option all the way from a value of 1 to a value of 6. I have deleted the following files from the data directory and tried to start the service but there has been no change in the error.

ib_logfile0
ib_logfile1
ibtmp1

I have tried renaming and/or moving the following files out of the data directory but, again, no change in the error and the service still will not start.

ibdata1
ib_buffer_pool

I moved every database directory in the data directory OUT of the data directory leaving only the mysql directory. Again though, no change in the error.

There are a number of hits on the exception in the title and I have checked the permissions and they are correct. As I said, this was supposed to be a simple update from 10.3.13 to 10.4.6 and I've done it on several other machines without any issues.

The server is running Windows Server 2008 R2 and is current on updates. The contents of the MySQL ini file are:

[client]
default-character-set  = utf8mb4
[mysqld]
port                   = 3306
datadir                = "D:/SQL_Data"
sql_mode               = "ERROR_FOR_DIVISION_BY_ZERO,NO_AUTO_CREATE_USER,NO_ENGINE_SUBSTITUTION"
optimizer_switch       = 'derived_merge=off'
tmpdir                 = 'D:/Temp'
character-set-server   = utf8mb4
collation_server       = 'utf8mb4_unicode_520_ci'
default-storage-engine = InnoDB
max_allowed_packet     = 128M
secure-file-priv       = ""

The complete .err file when the problem occurs is:

InnoDB: using atomic writes.
2019-07-09  8:24:11 0 [Note] InnoDB: The first innodb_system data file 'ibdata1' did not exist. A new tablespace will be created!
2019-07-09  8:24:11 0 [Note] InnoDB: Mutexes and rw_locks use Windows interlocked functions
2019-07-09  8:24:11 0 [Note] InnoDB: Uses event mutexes
2019-07-09  8:24:11 0 [Note] InnoDB: Compressed tables use zlib 1.2.11
2019-07-09  8:24:11 0 [Note] InnoDB: Number of pools: 1
2019-07-09  8:24:11 0 [Note] InnoDB: Using SSE2 crc32 instructions
2019-07-09  8:24:11 0 [Note] InnoDB: Initializing buffer pool, total size = 128M, instances = 1, chunk size = 128M
2019-07-09  8:24:11 0 [Note] InnoDB: Completed initialization of buffer pool
2019-07-09  8:24:11 0 [Note] InnoDB: Setting file '.\ibdata1' size to 12 MB. Physically writing the file full; Please wait ...
2019-07-09  8:24:11 0 [Note] InnoDB: File '.\ibdata1' size is now 12 MB.
2019-07-09  8:24:11 0 [Note] InnoDB: Setting log file .\ib_logfile101 size to 50331648 bytes
2019-07-09  8:24:11 0 [Note] InnoDB: Setting log file .\ib_logfile1 size to 50331648 bytes
2019-07-09  8:24:11 0 [Note] InnoDB: Renaming log file .\ib_logfile101 to .\ib_logfile0
2019-07-09  8:24:11 0 [Note] InnoDB: New log files created, LSN=17992
2019-07-09  8:24:11 0 [Note] InnoDB: Doublewrite buffer not found: creating new
2019-07-09  8:24:11 0 [Note] InnoDB: Doublewrite buffer created
2019-07-09  8:24:11 0 [Note] InnoDB: 128 out of 128 rollback segments are active.
2019-07-09  8:24:11 0 [Note] InnoDB: Creating foreign key constraint system tables.
2019-07-09  8:24:11 0 [Note] InnoDB: Creating tablespace and datafile system tables.
2019-07-09  8:24:11 0 [Note] InnoDB: Creating sys_virtual system tables.
2019-07-09  8:24:11 0 [Note] InnoDB: Creating shared tablespace for temporary tables
2019-07-09  8:24:11 0 [Note] InnoDB: Setting file '.\ibtmp1' size to 12 MB. Physically writing the file full; Please wait ...
2019-07-09  8:24:11 0 [Note] InnoDB: File '.\ibtmp1' size is now 12 MB.
2019-07-09  8:24:11 0 [Note] InnoDB: 10.4.6 started; log sequence number 0; transaction id 7
2019-07-09  8:24:11 0 [Note] Plugin 'FEEDBACK' is disabled.
2019-07-09  8:24:11 0 [Note] Server socket created on IP: '::'.
190709  8:24:11 [ERROR] mysqld got exception 0xc0000005 ;
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.4.6-MariaDB
key_buffer_size=134217728
read_buffer_size=131072
max_used_connections=0
max_threads=65537
thread_count=6
It is possible that mysqld could use up to 
key_buffer_size + (read_buffer_size + sort_buffer_size)*max_threads = 136381 K  bytes of memory
Hope that's ok; if not, decrease some variables in the equation.

Thread pointer: 0x1b2da008
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...
mysqld.exe!get_magic_sort()[sql_acl_getsort.ic:158]
mysqld.exe!acl_load()[sql_acl.cc:2353]
mysqld.exe!acl_reload()[sql_acl.cc:2693]
mysqld.exe!acl_init()[sql_acl.cc:2278]
mysqld.exe!win_main()[mysqld.cc:5763]
mysqld.exe!mysql_service()[mysqld.cc:5968]
ucrtbase.DLL!_crt_at_quick_exit()
kernel32.dll!BaseThreadInitThunk()
ntdll.dll!RtlUserThreadStart()

Trying to get some variables.
Some pointers may be invalid and cause the dump to abort.
Query (0x0): 
Connection ID (thread ID): 0
Status: NOT_KILLED

Optimizer switch: index_merge=on,index_merge_union=on,index_merge_sort_union=on,index_merge_intersection=on,index_merge_sort_intersection=off,engine_condition_pushdown=off,index_condition_pushdown=on,derived_merge=off,derived_with_keys=on,firstmatch=on,loosescan=on,materialization=on,in_to_exists=on,semijoin=on,partial_match_rowid_merge=on,partial_match_table_scan=on,subquery_cache=on,mrr=off,mrr_cost_based=off,mrr_sort_keys=off,outer_join_with_cache=on,semijoin_with_cache=on,join_cache_incremental=on,join_cache_hashed=on,join_cache_bka=on,optimize_join_buffer_size=on,table_elimination=on,extended_keys=on,exists_to_in=on,orderby_uses_equalities=on,condition_pushdown_for_derived=on,split_materialized=on,condition_pushdown_for_subquery=on,rowid_filter=on,condition_pushdown_from_having=on

The manual page at http://dev.mysql.com/doc/mysql/en/crashing.html contains
information that should help you find out what is causing the crash.
Writing a core file at D:\SQL_Data\

Best Answer

Fixed the issue (MariaDB 10.4.6 / Arch-Linux) by updating the conf values in the file /etc/my.cnf with the conf values from the previous/pre-update my.cnf file.

After the update to 10.4.6, by default, this file (/etc/my.cnf) contained empty/commented-out sections for [client] and [client-server], and no entries for the mysqld conf options.

Note:

Server specific detail:

After the update, the original (pre-update/working config) my.cnf file was renamed to my.cnf.pacsave, and the update created a new file my.cnf.pacnew with no conf values set for mysqld section.