190329 14:12:39 mysqld_safe Starting mysqld daemon with databases from /var/lib/mysql 190329 14:12:39 [Note] /usr/libexec/mysqld (mysqld 5.5.60-MariaDB) starting as process 23326 ... 190329 14:12:39 InnoDB: The InnoDB memory heap is disabled 190329 14:12:39 InnoDB: Mutexes and rw_locks use GCC atomic builtins 190329 14:12:39 InnoDB: Compressed tables use zlib 1.2.7 190329 14:12:39 InnoDB: Using Linux native AIO 190329 14:12:39 InnoDB: Initializing buffer pool, size = 128.0M 190329 14:12:39 InnoDB: Completed initialization of buffer pool InnoDB: The first specified data file ./ibdata1 did not exist: InnoDB: a new database to be created! 190329 14:12:39 InnoDB: Setting file ./ibdata1 size to 10 MB InnoDB: Database physically writes the file full: wait... 190329 14:12:39 InnoDB: Log file ./ib_logfile0 did not exist: new to be created InnoDB: Setting log file ./ib_logfile0 size to 5 MB InnoDB: Database physically writes the file full: wait... 190329 14:12:39 InnoDB: Log file ./ib_logfile1 did not exist: new to be created InnoDB: Setting log file ./ib_logfile1 size to 5 MB InnoDB: Database physically writes the file full: wait... InnoDB: Doublewrite buffer not found: creating new InnoDB: Doublewrite buffer created InnoDB: 127 rollback segment(s) active. InnoDB: Creating foreign key constraint system tables InnoDB: Foreign key constraint system tables created 190329 14:12:39 InnoDB: Waiting for the background threads to start 190329 14:12:40 Percona XtraDB (http://www.percona.com) 5.5.59-MariaDB-38.11 started; log sequence number 0 190329 14:12:40 [Note] Plugin 'FEEDBACK' is disabled. 190329 14:12:40 [Note] Server socket created on IP: '0.0.0.0'. 190329 14:12:40 [Note] Event Scheduler: Loaded 0 events 190329 14:12:40 [Note] /usr/libexec/mysqld: ready for connections. Version: '5.5.60-MariaDB' socket: '/var/lib/mysql/mysql.sock' port: 3306 MariaDB Server 190404 14:20:54 [Note] /usr/libexec/mysqld: Normal shutdown 190404 14:20:54 [Note] Event Scheduler: Purging the queue. 0 events 190404 14:20:54 InnoDB: Starting shutdown... 190404 14:20:58 InnoDB: Shutdown completed; log sequence number 1900294 190404 14:20:58 [Note] /usr/libexec/mysqld: Shutdown complete 190404 14:20:58 mysqld_safe mysqld from pid file /var/run/mariadb/mariadb.pid ended 190404 14:23:10 mysqld_safe Starting mysqld daemon with databases from /data/mysql 190404 14:23:10 [Note] /usr/libexec/mysqld (mysqld 5.5.60-MariaDB) starting as process 7661 ... 190404 14:23:10 InnoDB: The InnoDB memory heap is disabled 190404 14:23:10 InnoDB: Mutexes and rw_locks use GCC atomic builtins 190404 14:23:10 InnoDB: Compressed tables use zlib 1.2.7 190404 14:23:10 InnoDB: Using Linux native AIO 190404 14:23:10 InnoDB: Initializing buffer pool, size = 128.0M 190404 14:23:10 InnoDB: Completed initialization of buffer pool 190404 14:23:10 InnoDB: highest supported file format is Barracuda. 190404 14:23:10 InnoDB: Waiting for the background threads to start 190404 14:23:11 Percona XtraDB (http://www.percona.com) 5.5.59-MariaDB-38.11 started; log sequence number 1900294 190404 14:23:11 [Note] Plugin 'FEEDBACK' is disabled. 190404 14:23:11 [Note] Server socket created on IP: '0.0.0.0'. 190404 14:23:11 [Note] Event Scheduler: Loaded 0 events 190404 14:23:11 [Note] /usr/libexec/mysqld: ready for connections. Version: '5.5.60-MariaDB' socket: '/data/mysql/mysql.sock' port: 3306 MariaDB Server 190404 14:28:20 [Note] /usr/libexec/mysqld: Normal shutdown 190404 14:28:20 [Note] Event Scheduler: Purging the queue. 0 events 190404 14:28:20 InnoDB: Starting shutdown... 190404 14:28:21 InnoDB: Shutdown completed; log sequence number 1900294 190404 14:28:21 [Note] /usr/libexec/mysqld: Shutdown complete 190404 14:28:21 mysqld_safe mysqld from pid file /var/run/mariadb/mariadb.pid ended 190404 14:28:21 mysqld_safe Starting mysqld daemon with databases from /data/mysql 190404 14:28:21 [Note] /usr/libexec/mysqld (mysqld 5.5.60-MariaDB) starting as process 7937 ... 190404 14:28:21 InnoDB: The InnoDB memory heap is disabled 190404 14:28:21 InnoDB: Mutexes and rw_locks use GCC atomic builtins 190404 14:28:21 InnoDB: Compressed tables use zlib 1.2.7 190404 14:28:21 InnoDB: Using Linux native AIO 190404 14:28:21 InnoDB: Initializing buffer pool, size = 128.0M 190404 14:28:21 InnoDB: Completed initialization of buffer pool 190404 14:28:21 InnoDB: highest supported file format is Barracuda. 190404 14:28:21 InnoDB: Waiting for the background threads to start 190404 14:28:22 Percona XtraDB (http://www.percona.com) 5.5.59-MariaDB-38.11 started; log sequence number 1900294 190404 14:28:22 [Note] Plugin 'FEEDBACK' is disabled. 190404 14:28:22 [Note] Server socket created on IP: '0.0.0.0'. 190404 14:28:22 [Note] Event Scheduler: Loaded 0 events 190404 14:28:22 [Note] /usr/libexec/mysqld: ready for connections. Version: '5.5.60-MariaDB' socket: '/data/mysql/mysql.sock' port: 3306 MariaDB Server 190405 10:30:39 InnoDB: Error: the OS said file flush did not succeed 190405 10:30:39 InnoDB: Operating system error number 5 in a file operation. InnoDB: Error number 5 means 'Input/output error'. InnoDB: Some operating system error numbers are described at InnoDB: http://dev.mysql.com/doc/refman/5.5/en/operating-system-error-codes.html InnoDB: File operation call: 'flush'. InnoDB: Cannot continue operation. 190405 10:30:39 mysqld_safe Number of processes running now: 0 190405 10:30:39 mysqld_safe mysqld restarted 190405 10:30:39 [Note] /usr/libexec/mysqld (mysqld 5.5.60-MariaDB) starting as process 30371 ... 190405 10:30:39 InnoDB: The InnoDB memory heap is disabled 190405 10:30:39 InnoDB: Mutexes and rw_locks use GCC atomic builtins 190405 10:30:39 InnoDB: Compressed tables use zlib 1.2.7 190405 10:30:39 InnoDB: Using Linux native AIO 190405 10:30:39 InnoDB: Initializing buffer pool, size = 128.0M 190405 10:30:39 InnoDB: Completed initialization of buffer pool 190405 10:30:39 InnoDB: highest supported file format is Barracuda. 190405 10:30:39 InnoDB: Starting crash recovery from checkpoint LSN=7588126 InnoDB: Restoring possible half-written data pages from the doublewrite buffer... 190405 10:30:39 InnoDB: Starting final batch to recover 1 pages from redo log 190405 10:30:39 InnoDB: Waiting for the background threads to start 190405 10:30:40 Percona XtraDB (http://www.percona.com) 5.5.59-MariaDB-38.11 started; log sequence number 7588727 190405 10:30:40 [Note] Plugin 'FEEDBACK' is disabled. 190405 10:30:40 [Note] Server socket created on IP: '0.0.0.0'. 190405 10:30:40 [Note] Event Scheduler: Loaded 0 events 190405 10:30:40 [Note] /usr/libexec/mysqld: ready for connections. Version: '5.5.60-MariaDB' socket: '/data/mysql/mysql.sock' port: 3306 MariaDB Server 190408 6:48:49 InnoDB: Error: the OS said file flush did not succeed 190408 6:48:49 InnoDB: Operating system error number 5 in a file operation. InnoDB: Error number 5 means 'Input/output error'. InnoDB: Some operating system error numbers are described at InnoDB: http://dev.mysql.com/doc/refman/5.5/en/operating-system-error-codes.html InnoDB: File operation call: 'flush'. InnoDB: Cannot continue operation. 190408 06:48:49 mysqld_safe Number of processes running now: 0 190408 06:48:49 mysqld_safe mysqld restarted 190408 6:48:49 [Note] /usr/libexec/mysqld (mysqld 5.5.60-MariaDB) starting as process 1883 ... 190408 6:48:49 InnoDB: The InnoDB memory heap is disabled 190408 6:48:49 InnoDB: Mutexes and rw_locks use GCC atomic builtins 190408 6:48:49 InnoDB: Compressed tables use zlib 1.2.7 190408 6:48:49 InnoDB: Using Linux native AIO 190408 6:48:49 InnoDB: Initializing buffer pool, size = 128.0M 190408 6:48:49 InnoDB: Completed initialization of buffer pool 190408 6:48:49 InnoDB: highest supported file format is Barracuda. 190408 6:48:49 InnoDB: Starting crash recovery from checkpoint LSN=7913201 InnoDB: Restoring possible half-written data pages from the doublewrite buffer... 190408 6:48:49 InnoDB: Starting final batch to recover 3 pages from redo log 190408 6:48:50 InnoDB: Waiting for the background threads to start 190408 6:48:51 Percona XtraDB (http://www.percona.com) 5.5.59-MariaDB-38.11 started; log sequence number 7913598 190408 6:48:51 [Note] Plugin 'FEEDBACK' is disabled. 190408 6:48:51 [Note] Server socket created on IP: '0.0.0.0'. 190408 6:48:51 [Note] Event Scheduler: Loaded 0 events 190408 6:48:51 [Note] /usr/libexec/mysqld: ready for connections. Version: '5.5.60-MariaDB' socket: '/data/mysql/mysql.sock' port: 3306 MariaDB Server 190408 10:03:35 InnoDB: Assertion failure in thread 139994257680128 in file fut0lst.ic line 83 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: http://dev.mysql.com/doc/refman/5.5/en/forcing-innodb-recovery.html InnoDB: about forcing recovery. 190408 10:03:35 [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 http://kb.askmonty.org/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: 5.5.60-MariaDB key_buffer_size=134217728 read_buffer_size=131072 max_used_connections=9 max_threads=153 thread_count=1 It is possible that mysqld could use up to key_buffer_size + (read_buffer_size + sort_buffer_size)*max_threads = 466718 K bytes of memory Hope that's ok; if not, decrease some variables in the equation. Thread pointer: 0x55fc87399890 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 = 0x7f52f3ffdd80 thread_stack 0x48000 /usr/libexec/mysqld(my_print_stacktrace+0x3d)[0x55fc8523ecbd] /usr/libexec/mysqld(handle_fatal_signal+0x515)[0x55fc84e534a5] sigaction.c:0(__restore_rt)[0x7f5328ec65d0] :0(__GI_raise)[0x7f53275f0207] :0(__GI_abort)[0x7f53275f18f8] /usr/libexec/mysqld(+0x2d73b7)[0x55fc84c863b7] /usr/libexec/mysqld(+0x6f87d0)[0x55fc850a77d0] /usr/libexec/mysqld(+0x657ade)[0x55fc85006ade] /usr/libexec/mysqld(+0x671153)[0x55fc85020153] /usr/libexec/mysqld(+0x666faf)[0x55fc85015faf] /usr/libexec/mysqld(+0x668d94)[0x55fc85017d94] /usr/libexec/mysqld(+0x66a6c7)[0x55fc850196c7] /usr/libexec/mysqld(+0x60a5a0)[0x55fc84fb95a0] /usr/libexec/mysqld(+0x60b54b)[0x55fc84fba54b] /usr/libexec/mysqld(_Z19ha_commit_one_phaseP3THDb+0x80)[0x55fc84e55ac0] /usr/libexec/mysqld(_Z15ha_commit_transP3THDb+0x356)[0x55fc84e56236] /usr/libexec/mysqld(_Z17trans_commit_stmtP3THD+0x1b)[0x55fc84de93bb] /usr/libexec/mysqld(_Z21mysql_execute_commandP3THD+0x3dc)[0x55fc84d219ec] /usr/libexec/mysqld(_Z11mysql_parseP3THDPcjP12Parser_state+0x125)[0x55fc84d28445] /usr/libexec/mysqld(_Z16dispatch_command19enum_server_commandP3THDPcj+0x1750)[0x55fc84d2a4a0] /usr/libexec/mysqld(_Z24do_handle_one_connectionP3THD+0x1c2)[0x55fc84ddca22] /usr/libexec/mysqld(handle_one_connection+0x4a)[0x55fc84ddcaca] pthread_create.c:0(start_thread)[0x7f5328ebedd5] /lib64/libc.so.6(clone+0x6d)[0x7f53276b7ead] Trying to get some variables. Some pointers may be invalid and cause the dump to abort. Query (0x7f52e8004c18): UPDATE `users` SET `lastActivity`='2019-04-08 08:03:35' WHERE `id`='1' Connection ID (thread ID): 557 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=on,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=off,table_elimination=on,extended_keys=off 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. 190408 10:03:36 mysqld_safe Number of processes running now: 0 190408 10:03:36 mysqld_safe mysqld restarted 190408 10:03:36 [Note] /usr/libexec/mysqld (mysqld 5.5.60-MariaDB) starting as process 19207 ... 190408 10:03:36 InnoDB: The InnoDB memory heap is disabled 190408 10:03:36 InnoDB: Mutexes and rw_locks use GCC atomic builtins 190408 10:03:36 InnoDB: Compressed tables use zlib 1.2.7 190408 10:03:36 InnoDB: Using Linux native AIO 190408 10:03:36 InnoDB: Initializing buffer pool, size = 128.0M 190408 10:03:36 InnoDB: Completed initialization of buffer pool 190408 10:03:36 InnoDB: highest supported file format is Barracuda. 190408 10:03:36 InnoDB: Starting crash recovery from checkpoint LSN=8171362 InnoDB: Restoring possible half-written data pages from the doublewrite buffer... 190408 10:03:36 InnoDB: Starting final batch to recover 8 pages from redo log 190408 10:03:36 InnoDB: Waiting for the background threads to start 190408 10:03:37 Percona XtraDB (http://www.percona.com) 5.5.59-MariaDB-38.11 started; log sequence number 8174474 190408 10:03:37 [Note] Plugin 'FEEDBACK' is disabled. 190408 10:03:37 [Note] Server socket created on IP: '0.0.0.0'. 190408 10:03:37 [Note] Event Scheduler: Loaded 0 events 190408 10:03:37 [Note] /usr/libexec/mysqld: ready for connections. Version: '5.5.60-MariaDB' socket: '/data/mysql/mysql.sock' port: 3306 MariaDB Server 190410 12:13:26 InnoDB: Assertion failure in thread 140588576577280 in file fut0lst.ic line 83 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: http://dev.mysql.com/doc/refman/5.5/en/forcing-innodb-recovery.html InnoDB: about forcing recovery. 190410 12:13:26 [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 http://kb.askmonty.org/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: 5.5.60-MariaDB key_buffer_size=134217728 read_buffer_size=131072 max_used_connections=7 max_threads=153 thread_count=1 It is possible that mysqld could use up to key_buffer_size + (read_buffer_size + sort_buffer_size)*max_threads = 466718 K bytes of memory Hope that's ok; if not, decrease some variables in the equation. Thread pointer: 0x55b1e3c6a350 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 = 0x7fdd542a8d80 thread_stack 0x48000 /usr/libexec/mysqld(my_print_stacktrace+0x3d)[0x55b1e0372cbd] /usr/libexec/mysqld(handle_fatal_signal+0x515)[0x55b1dff874a5] sigaction.c:0(__restore_rt)[0x7fdd751335d0] :0(__GI_raise)[0x7fdd7385d207] :0(__GI_abort)[0x7fdd7385e8f8] /usr/libexec/mysqld(+0x2d73b7)[0x55b1dfdba3b7] /usr/libexec/mysqld(+0x6f87d0)[0x55b1e01db7d0] /usr/libexec/mysqld(+0x657ade)[0x55b1e013aade] /usr/libexec/mysqld(+0x671153)[0x55b1e0154153] /usr/libexec/mysqld(+0x666faf)[0x55b1e0149faf] /usr/libexec/mysqld(+0x668d94)[0x55b1e014bd94] /usr/libexec/mysqld(+0x66a6c7)[0x55b1e014d6c7] /usr/libexec/mysqld(+0x60a5a0)[0x55b1e00ed5a0] /usr/libexec/mysqld(+0x60b54b)[0x55b1e00ee54b] /usr/libexec/mysqld(_Z19ha_commit_one_phaseP3THDb+0x80)[0x55b1dff89ac0] /usr/libexec/mysqld(_Z15ha_commit_transP3THDb+0x356)[0x55b1dff8a236] /usr/libexec/mysqld(_Z17trans_commit_stmtP3THD+0x1b)[0x55b1dff1d3bb] /usr/libexec/mysqld(_Z21mysql_execute_commandP3THD+0x3dc)[0x55b1dfe559ec] /usr/libexec/mysqld(_Z11mysql_parseP3THDPcjP12Parser_state+0x125)[0x55b1dfe5c445] /usr/libexec/mysqld(_Z16dispatch_command19enum_server_commandP3THDPcj+0x1750)[0x55b1dfe5e4a0] /usr/libexec/mysqld(_Z24do_handle_one_connectionP3THD+0x1c2)[0x55b1dff10a22] /usr/libexec/mysqld(handle_one_connection+0x4a)[0x55b1dff10aca] pthread_create.c:0(start_thread)[0x7fdd7512bdd5] /lib64/libc.so.6(clone+0x6d)[0x7fdd73924ead] Trying to get some variables. Some pointers may be invalid and cause the dump to abort. Query (0x7fdd6c0029f8): UPDATE `ipaddresses` SET `lastSeen`='2019-04-10 10:13:26' WHERE `id`='5772' Connection ID (thread ID): 945 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=on,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=off,table_elimination=on,extended_keys=off 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. 190410 12:13:26 mysqld_safe Number of processes running now: 0 190410 12:13:27 mysqld_safe mysqld restarted 190410 12:13:27 [Note] /usr/libexec/mysqld (mysqld 5.5.60-MariaDB) starting as process 10890 ... 190410 12:13:27 InnoDB: The InnoDB memory heap is disabled 190410 12:13:27 InnoDB: Mutexes and rw_locks use GCC atomic builtins 190410 12:13:27 InnoDB: Compressed tables use zlib 1.2.7 190410 12:13:27 InnoDB: Using Linux native AIO 190410 12:13:27 InnoDB: Initializing buffer pool, size = 128.0M 190410 12:13:27 InnoDB: Completed initialization of buffer pool 190410 12:13:27 InnoDB: highest supported file format is Barracuda. 190410 12:13:27 InnoDB: Starting crash recovery from checkpoint LSN=8429385 InnoDB: Restoring possible half-written data pages from the doublewrite buffer... 190410 12:13:27 InnoDB: Starting final batch to recover 3 pages from redo log 190410 12:13:27 InnoDB: Waiting for the background threads to start 190410 12:13:28 Percona XtraDB (http://www.percona.com) 5.5.59-MariaDB-38.11 started; log sequence number 8449359 190410 12:13:28 [Note] Plugin 'FEEDBACK' is disabled. 190410 12:13:28 [Note] Server socket created on IP: '0.0.0.0'. 190410 12:13:28 [Note] Event Scheduler: Loaded 0 events 190410 12:13:28 [Note] /usr/libexec/mysqld: ready for connections. Version: '5.5.60-MariaDB' socket: '/data/mysql/mysql.sock' port: 3306 MariaDB Server 190410 12:13:40 InnoDB: Assertion failure in thread 139645697607424 in file fut0lst.ic line 83 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: http://dev.mysql.com/doc/refman/5.5/en/forcing-innodb-recovery.html InnoDB: about forcing recovery. 190410 12:13:40 [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 http://kb.askmonty.org/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: 5.5.60-MariaDB key_buffer_size=134217728 read_buffer_size=131072 max_used_connections=3 max_threads=153 thread_count=1 It is possible that mysqld could use up to key_buffer_size + (read_buffer_size + sort_buffer_size)*max_threads = 466718 K bytes of memory Hope that's ok; if not, decrease some variables in the equation. Thread pointer: 0x561c5ec949c0 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 = 0x7f01cc333d80 thread_stack 0x48000 /usr/libexec/mysqld(my_print_stacktrace+0x3d)[0x561c5d188cbd] /usr/libexec/mysqld(handle_fatal_signal+0x515)[0x561c5cd9d4a5] sigaction.c:0(__restore_rt)[0x7f01d0a3b5d0] :0(__GI_raise)[0x7f01cf165207] :0(__GI_abort)[0x7f01cf1668f8] /usr/libexec/mysqld(+0x2d73b7)[0x561c5cbd03b7] /usr/libexec/mysqld(+0x6f87d0)[0x561c5cff17d0] /usr/libexec/mysqld(+0x657ade)[0x561c5cf50ade] /usr/libexec/mysqld(+0x671153)[0x561c5cf6a153] /usr/libexec/mysqld(+0x666faf)[0x561c5cf5ffaf] /usr/libexec/mysqld(+0x668d94)[0x561c5cf61d94] /usr/libexec/mysqld(+0x66a6c7)[0x561c5cf636c7] /usr/libexec/mysqld(+0x60a5a0)[0x561c5cf035a0] /usr/libexec/mysqld(+0x60b54b)[0x561c5cf0454b] /usr/libexec/mysqld(_Z19ha_commit_one_phaseP3THDb+0x80)[0x561c5cd9fac0] /usr/libexec/mysqld(_Z15ha_commit_transP3THDb+0x356)[0x561c5cda0236] /usr/libexec/mysqld(_Z17trans_commit_stmtP3THD+0x1b)[0x561c5cd333bb] /usr/libexec/mysqld(_Z21mysql_execute_commandP3THD+0x3dc)[0x561c5cc6b9ec] /usr/libexec/mysqld(_Z11mysql_parseP3THDPcjP12Parser_state+0x125)[0x561c5cc72445] /usr/libexec/mysqld(_Z16dispatch_command19enum_server_commandP3THDPcj+0x1750)[0x561c5cc744a0] /usr/libexec/mysqld(_Z24do_handle_one_connectionP3THD+0x1c2)[0x561c5cd26a22] /usr/libexec/mysqld(handle_one_connection+0x4a)[0x561c5cd26aca] pthread_create.c:0(start_thread)[0x7f01d0a33dd5] /lib64/libc.so.6(clone+0x6d)[0x7f01cf22cead] Trying to get some variables. Some pointers may be invalid and cause the dump to abort. Query (0x7f0188004c38): UPDATE `ipaddresses` SET `lastSeen`='2019-04-10 10:13:40' WHERE `id`='5870' Connection ID (thread ID): 2 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=on,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=off,table_elimination=on,extended_keys=off 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. 190410 12:13:40 mysqld_safe Number of processes running now: 0 190410 12:13:40 mysqld_safe mysqld restarted 190410 12:13:40 [Note] /usr/libexec/mysqld (mysqld 5.5.60-MariaDB) starting as process 11459 ... 190410 12:13:40 InnoDB: The InnoDB memory heap is disabled 190410 12:13:40 InnoDB: Mutexes and rw_locks use GCC atomic builtins 190410 12:13:40 InnoDB: Compressed tables use zlib 1.2.7 190410 12:13:40 InnoDB: Using Linux native AIO 190410 12:13:40 InnoDB: Initializing buffer pool, size = 128.0M 190410 12:13:40 InnoDB: Completed initialization of buffer pool 190410 12:13:40 InnoDB: highest supported file format is Barracuda. 190410 12:13:40 InnoDB: Starting crash recovery from checkpoint LSN=8449359 InnoDB: Restoring possible half-written data pages from the doublewrite buffer... 190410 12:13:40 InnoDB: Starting final batch to recover 4 pages from redo log 190410 12:13:40 InnoDB: Waiting for the background threads to start 190410 12:13:41 Percona XtraDB (http://www.percona.com) 5.5.59-MariaDB-38.11 started; log sequence number 8487747 190410 12:13:41 [Note] Plugin 'FEEDBACK' is disabled. 190410 12:13:41 [Note] Server socket created on IP: '0.0.0.0'. 190410 12:13:41 [Note] Event Scheduler: Loaded 0 events 190410 12:13:41 [Note] /usr/libexec/mysqld: ready for connections. Version: '5.5.60-MariaDB' socket: '/data/mysql/mysql.sock' port: 3306 MariaDB Server 190410 12:13:54 InnoDB: Assertion failure in thread 140621728032512 in file fut0lst.ic line 83 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: http://dev.mysql.com/doc/refman/5.5/en/forcing-innodb-recovery.html InnoDB: about forcing recovery. 190410 12:13:54 [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 http://kb.askmonty.org/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: 5.5.60-MariaDB key_buffer_size=134217728 read_buffer_size=131072 max_used_connections=3 max_threads=153 thread_count=1 It is possible that mysqld could use up to key_buffer_size + (read_buffer_size + sort_buffer_size)*max_threads = 466718 K bytes of memory Hope that's ok; if not, decrease some variables in the equation. Thread pointer: 0x5610d64773d0 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 = 0x7fe50c259d80 thread_stack 0x48000 /usr/libexec/mysqld(my_print_stacktrace+0x3d)[0x5610d32d6cbd] /usr/libexec/mysqld(handle_fatal_signal+0x515)[0x5610d2eeb4a5] sigaction.c:0(__restore_rt)[0x7fe5136a95d0] :0(__GI_raise)[0x7fe511dd3207] :0(__GI_abort)[0x7fe511dd48f8] /usr/libexec/mysqld(+0x2d73b7)[0x5610d2d1e3b7] /usr/libexec/mysqld(+0x6f87d0)[0x5610d313f7d0] /usr/libexec/mysqld(+0x657ade)[0x5610d309eade] /usr/libexec/mysqld(+0x671153)[0x5610d30b8153] /usr/libexec/mysqld(+0x666faf)[0x5610d30adfaf] /usr/libexec/mysqld(+0x668d94)[0x5610d30afd94] /usr/libexec/mysqld(+0x66a6c7)[0x5610d30b16c7] /usr/libexec/mysqld(+0x60a5a0)[0x5610d30515a0] /usr/libexec/mysqld(+0x60b54b)[0x5610d305254b] /usr/libexec/mysqld(_Z19ha_commit_one_phaseP3THDb+0x80)[0x5610d2eedac0] /usr/libexec/mysqld(_Z15ha_commit_transP3THDb+0x356)[0x5610d2eee236] /usr/libexec/mysqld(_Z17trans_commit_stmtP3THD+0x1b)[0x5610d2e813bb] /usr/libexec/mysqld(_Z21mysql_execute_commandP3THD+0x3dc)[0x5610d2db99ec] /usr/libexec/mysqld(_Z11mysql_parseP3THDPcjP12Parser_state+0x125)[0x5610d2dc0445] /usr/libexec/mysqld(_Z16dispatch_command19enum_server_commandP3THDPcj+0x1750)[0x5610d2dc24a0] /usr/libexec/mysqld(_Z24do_handle_one_connectionP3THD+0x1c2)[0x5610d2e74a22] /usr/libexec/mysqld(handle_one_connection+0x4a)[0x5610d2e74aca] pthread_create.c:0(start_thread)[0x7fe5136a1dd5] /lib64/libc.so.6(clone+0x6d)[0x7fe511e9aead] Trying to get some variables. Some pointers may be invalid and cause the dump to abort. Query (0x7fe4cc004c38): UPDATE `ipaddresses` SET `lastSeen`='2019-04-10 10:13:54' WHERE `id`='5867' Connection ID (thread ID): 2 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=on,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=off,table_elimination=on,extended_keys=off 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. 190410 12:13:54 mysqld_safe Number of processes running now: 0 190410 12:13:54 mysqld_safe mysqld restarted 190410 12:13:54 [Note] /usr/libexec/mysqld (mysqld 5.5.60-MariaDB) starting as process 12030 ... 190410 12:13:54 InnoDB: The InnoDB memory heap is disabled 190410 12:13:54 InnoDB: Mutexes and rw_locks use GCC atomic builtins 190410 12:13:54 InnoDB: Compressed tables use zlib 1.2.7 190410 12:13:54 InnoDB: Using Linux native AIO 190410 12:13:54 InnoDB: Initializing buffer pool, size = 128.0M 190410 12:13:54 InnoDB: Completed initialization of buffer pool 190410 12:13:54 InnoDB: highest supported file format is Barracuda. 190410 12:13:54 InnoDB: Starting crash recovery from checkpoint LSN=8487747 InnoDB: Restoring possible half-written data pages from the doublewrite buffer... 190410 12:13:54 InnoDB: Starting final batch to recover 4 pages from redo log 190410 12:13:55 InnoDB: Waiting for the background threads to start 190410 12:13:56 Percona XtraDB (http://www.percona.com) 5.5.59-MariaDB-38.11 started; log sequence number 8520180 190410 12:13:56 [Note] Plugin 'FEEDBACK' is disabled. 190410 12:13:56 [Note] Server socket created on IP: '0.0.0.0'. 190410 12:13:56 [Note] Event Scheduler: Loaded 0 events 190410 12:13:56 [Note] /usr/libexec/mysqld: ready for connections. Version: '5.5.60-MariaDB' socket: '/data/mysql/mysql.sock' port: 3306 MariaDB Server 190410 13:25:19 InnoDB: Assertion failure in thread 140345076991744 in file fut0lst.ic line 83 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: http://dev.mysql.com/doc/refman/5.5/en/forcing-innodb-recovery.html InnoDB: about forcing recovery. 190410 13:25:19 [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 http://kb.askmonty.org/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: 5.5.60-MariaDB key_buffer_size=134217728 read_buffer_size=131072 max_used_connections=2 max_threads=153 thread_count=1 It is possible that mysqld could use up to key_buffer_size + (read_buffer_size + sort_buffer_size)*max_threads = 466718 K bytes of memory Hope that's ok; if not, decrease some variables in the equation. Thread pointer: 0x556b35e4fd30 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 = 0x7fa4a275bd80 thread_stack 0x48000 /usr/libexec/mysqld(my_print_stacktrace+0x3d)[0x556b33502cbd] /usr/libexec/mysqld(handle_fatal_signal+0x515)[0x556b331174a5] sigaction.c:0(__restore_rt)[0x7fa4bf9ec5d0] :0(__GI_raise)[0x7fa4be116207] :0(__GI_abort)[0x7fa4be1178f8] /usr/libexec/mysqld(+0x2d73b7)[0x556b32f4a3b7] /usr/libexec/mysqld(+0x6f87d0)[0x556b3336b7d0] /usr/libexec/mysqld(+0x657ade)[0x556b332caade] /usr/libexec/mysqld(+0x671153)[0x556b332e4153] /usr/libexec/mysqld(+0x666faf)[0x556b332d9faf] /usr/libexec/mysqld(+0x668d94)[0x556b332dbd94] /usr/libexec/mysqld(+0x66a6c7)[0x556b332dd6c7] /usr/libexec/mysqld(+0x60a5a0)[0x556b3327d5a0] /usr/libexec/mysqld(+0x60b54b)[0x556b3327e54b] /usr/libexec/mysqld(_Z19ha_commit_one_phaseP3THDb+0x80)[0x556b33119ac0] /usr/libexec/mysqld(_Z15ha_commit_transP3THDb+0x356)[0x556b3311a236] /usr/libexec/mysqld(_Z17trans_commit_stmtP3THD+0x1b)[0x556b330ad3bb] /usr/libexec/mysqld(_Z21mysql_execute_commandP3THD+0x3dc)[0x556b32fe59ec] /usr/libexec/mysqld(_Z11mysql_parseP3THDPcjP12Parser_state+0x125)[0x556b32fec445] /usr/libexec/mysqld(_Z16dispatch_command19enum_server_commandP3THDPcj+0x1750)[0x556b32fee4a0] /usr/libexec/mysqld(_Z24do_handle_one_connectionP3THD+0x1c2)[0x556b330a0a22] /usr/libexec/mysqld(handle_one_connection+0x4a)[0x556b330a0aca] pthread_create.c:0(start_thread)[0x7fa4bf9e4dd5] /lib64/libc.so.6(clone+0x6d)[0x7fa4be1ddead] Trying to get some variables. Some pointers may be invalid and cause the dump to abort. Query (0x7fa478004c18): UPDATE `users` SET `lastActivity`='2019-04-10 11:25:19' WHERE `id`='1' Connection ID (thread ID): 65 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=on,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=off,table_elimination=on,extended_keys=off 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. 190410 13:25:20 mysqld_safe Number of processes running now: 0 190410 13:25:20 mysqld_safe mysqld restarted 190410 13:25:20 [Note] /usr/libexec/mysqld (mysqld 5.5.60-MariaDB) starting as process 13618 ... 190410 13:25:20 InnoDB: The InnoDB memory heap is disabled 190410 13:25:20 InnoDB: Mutexes and rw_locks use GCC atomic builtins 190410 13:25:20 InnoDB: Compressed tables use zlib 1.2.7 190410 13:25:20 InnoDB: Using Linux native AIO 190410 13:25:20 InnoDB: Initializing buffer pool, size = 128.0M 190410 13:25:20 InnoDB: Completed initialization of buffer pool 190410 13:25:20 InnoDB: highest supported file format is Barracuda. InnoDB: The log sequence number in ibdata files does not match InnoDB: the log sequence number in the ib_logfiles! InnoDB: Restoring possible half-written data pages from the doublewrite buffer... 190410 13:25:20 InnoDB: Waiting for the background threads to start 190410 13:25:21 Percona XtraDB (http://www.percona.com) 5.5.59-MariaDB-38.11 started; log sequence number 8536079 190410 13:25:21 [Note] Plugin 'FEEDBACK' is disabled. 190410 13:25:21 [Note] Server socket created on IP: '0.0.0.0'. 190410 13:25:21 [Note] Event Scheduler: Loaded 0 events 190410 13:25:21 [Note] /usr/libexec/mysqld: ready for connections. Version: '5.5.60-MariaDB' socket: '/data/mysql/mysql.sock' port: 3306 MariaDB Server 190411 15:37:06 InnoDB: Assertion failure in thread 139630256940800 in file fut0lst.ic line 83 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: http://dev.mysql.com/doc/refman/5.5/en/forcing-innodb-recovery.html InnoDB: about forcing recovery. 190411 15:37:06 [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 http://kb.askmonty.org/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: 5.5.60-MariaDB key_buffer_size=134217728 read_buffer_size=131072 max_used_connections=7 max_threads=153 thread_count=1 It is possible that mysqld could use up to key_buffer_size + (read_buffer_size + sort_buffer_size)*max_threads = 466718 K bytes of memory Hope that's ok; if not, decrease some variables in the equation. Thread pointer: 0x562d75460040 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 = 0x7efe33dd5d80 thread_stack 0x48000 /usr/libexec/mysqld(my_print_stacktrace+0x3d)[0x562d72356cbd] /usr/libexec/mysqld(handle_fatal_signal+0x515)[0x562d71f6b4a5] sigaction.c:0(__restore_rt)[0x7efe5112b5d0] :0(__GI_raise)[0x7efe4f855207] :0(__GI_abort)[0x7efe4f8568f8] /usr/libexec/mysqld(+0x2d73b7)[0x562d71d9e3b7] /usr/libexec/mysqld(+0x6f87d0)[0x562d721bf7d0] /usr/libexec/mysqld(+0x657ade)[0x562d7211eade] /usr/libexec/mysqld(+0x671153)[0x562d72138153] /usr/libexec/mysqld(+0x666faf)[0x562d7212dfaf] /usr/libexec/mysqld(+0x668d94)[0x562d7212fd94] /usr/libexec/mysqld(+0x66a6c7)[0x562d721316c7] /usr/libexec/mysqld(+0x60a5a0)[0x562d720d15a0] /usr/libexec/mysqld(+0x60b54b)[0x562d720d254b] /usr/libexec/mysqld(_Z19ha_commit_one_phaseP3THDb+0x80)[0x562d71f6dac0] /usr/libexec/mysqld(_Z15ha_commit_transP3THDb+0x356)[0x562d71f6e236] /usr/libexec/mysqld(_Z17trans_commit_stmtP3THD+0x1b)[0x562d71f013bb] /usr/libexec/mysqld(_Z21mysql_execute_commandP3THD+0x3dc)[0x562d71e399ec] /usr/libexec/mysqld(_Z11mysql_parseP3THDPcjP12Parser_state+0x125)[0x562d71e40445] /usr/libexec/mysqld(_Z16dispatch_command19enum_server_commandP3THDPcj+0x1750)[0x562d71e424a0] /usr/libexec/mysqld(_Z24do_handle_one_connectionP3THD+0x1c2)[0x562d71ef4a22] /usr/libexec/mysqld(handle_one_connection+0x4a)[0x562d71ef4aca] pthread_create.c:0(start_thread)[0x7efe51123dd5] /lib64/libc.so.6(clone+0x6d)[0x7efe4f91cead] Trying to get some variables. Some pointers may be invalid and cause the dump to abort. Query (0x7efe18004c18): UPDATE `users` SET `lastActivity`='2019-04-11 13:37:06' WHERE `id`='2' Connection ID (thread ID): 390 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=on,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=off,table_elimination=on,extended_keys=off 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. 190411 15:37:06 mysqld_safe Number of processes running now: 0 190411 15:37:06 mysqld_safe mysqld restarted 190411 15:37:06 [Note] /usr/libexec/mysqld (mysqld 5.5.60-MariaDB) starting as process 12550 ... 190411 15:37:06 InnoDB: The InnoDB memory heap is disabled 190411 15:37:06 InnoDB: Mutexes and rw_locks use GCC atomic builtins 190411 15:37:06 InnoDB: Compressed tables use zlib 1.2.7 190411 15:37:06 InnoDB: Using Linux native AIO 190411 15:37:06 InnoDB: Initializing buffer pool, size = 128.0M 190411 15:37:06 InnoDB: Completed initialization of buffer pool 190411 15:37:06 InnoDB: highest supported file format is Barracuda. 190411 15:37:06 InnoDB: Starting crash recovery from checkpoint LSN=8609991 InnoDB: Restoring possible half-written data pages from the doublewrite buffer... 190411 15:37:06 InnoDB: Starting final batch to recover 9 pages from redo log 190411 15:37:07 InnoDB: Waiting for the background threads to start 190411 15:37:08 Percona XtraDB (http://www.percona.com) 5.5.59-MariaDB-38.11 started; log sequence number 8614149 190411 15:37:08 [Note] Plugin 'FEEDBACK' is disabled. 190411 15:37:08 [Note] Server socket created on IP: '0.0.0.0'. 190411 15:37:08 [Note] Event Scheduler: Loaded 0 events 190411 15:37:08 [Note] /usr/libexec/mysqld: ready for connections. Version: '5.5.60-MariaDB' socket: '/data/mysql/mysql.sock' port: 3306 MariaDB Server 190411 15:58:01 InnoDB: Assertion failure in thread 139949523191552 in file fut0lst.ic line 83 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: http://dev.mysql.com/doc/refman/5.5/en/forcing-innodb-recovery.html InnoDB: about forcing recovery. 190411 15:58:01 [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 http://kb.askmonty.org/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: 5.5.60-MariaDB key_buffer_size=134217728 read_buffer_size=131072 max_used_connections=12 max_threads=153 thread_count=1 It is possible that mysqld could use up to key_buffer_size + (read_buffer_size + sort_buffer_size)*max_threads = 466718 K bytes of memory Hope that's ok; if not, decrease some variables in the equation. Thread pointer: 0x55ac1849a330 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 = 0x7f48899dbd80 thread_stack 0x48000 /usr/libexec/mysqld(my_print_stacktrace+0x3d)[0x55ac15b73cbd] /usr/libexec/mysqld(handle_fatal_signal+0x515)[0x55ac157884a5] sigaction.c:0(__restore_rt)[0x7f48a6ca95d0] :0(__GI_raise)[0x7f48a53d3207] :0(__GI_abort)[0x7f48a53d48f8] /usr/libexec/mysqld(+0x2d73b7)[0x55ac155bb3b7] /usr/libexec/mysqld(+0x6f87d0)[0x55ac159dc7d0] /usr/libexec/mysqld(+0x657ade)[0x55ac1593bade] /usr/libexec/mysqld(+0x671153)[0x55ac15955153] /usr/libexec/mysqld(+0x666faf)[0x55ac1594afaf] /usr/libexec/mysqld(+0x668d94)[0x55ac1594cd94] /usr/libexec/mysqld(+0x66a6c7)[0x55ac1594e6c7] /usr/libexec/mysqld(+0x60a5a0)[0x55ac158ee5a0] /usr/libexec/mysqld(+0x60b54b)[0x55ac158ef54b] /usr/libexec/mysqld(_Z19ha_commit_one_phaseP3THDb+0x80)[0x55ac1578aac0] /usr/libexec/mysqld(_Z15ha_commit_transP3THDb+0x356)[0x55ac1578b236] /usr/libexec/mysqld(_Z17trans_commit_stmtP3THD+0x1b)[0x55ac1571e3bb] /usr/libexec/mysqld(_Z21mysql_execute_commandP3THD+0x3dc)[0x55ac156569ec] /usr/libexec/mysqld(_Z11mysql_parseP3THDPcjP12Parser_state+0x125)[0x55ac1565d445] /usr/libexec/mysqld(_Z16dispatch_command19enum_server_commandP3THDPcj+0x1750)[0x55ac1565f4a0] /usr/libexec/mysqld(_Z24do_handle_one_connectionP3THD+0x1c2)[0x55ac15711a22] /usr/libexec/mysqld(handle_one_connection+0x4a)[0x55ac15711aca] pthread_create.c:0(start_thread)[0x7f48a6ca1dd5] /lib64/libc.so.6(clone+0x6d)[0x7f48a549aead] Trying to get some variables. Some pointers may be invalid and cause the dump to abort. Query (0x55ac183d5808): update `settings` set `vcheckDate`='2019-04-11 13:58:01' Connection ID (thread ID): 26 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=on,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=off,table_elimination=on,extended_keys=off 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. 190411 15:58:02 mysqld_safe Number of processes running now: 0 190411 15:58:02 mysqld_safe mysqld restarted 190411 15:58:02 [Note] /usr/libexec/mysqld (mysqld 5.5.60-MariaDB) starting as process 13223 ... 190411 15:58:02 InnoDB: The InnoDB memory heap is disabled 190411 15:58:02 InnoDB: Mutexes and rw_locks use GCC atomic builtins 190411 15:58:02 InnoDB: Compressed tables use zlib 1.2.7 190411 15:58:02 InnoDB: Using Linux native AIO 190411 15:58:02 InnoDB: Initializing buffer pool, size = 128.0M 190411 15:58:02 InnoDB: Completed initialization of buffer pool 190411 15:58:02 InnoDB: highest supported file format is Barracuda. 190411 15:58:02 InnoDB: Starting crash recovery from checkpoint LSN=8621983 InnoDB: Restoring possible half-written data pages from the doublewrite buffer... 190411 15:58:02 InnoDB: Starting final batch to recover 1 pages from redo log 190411 15:58:02 InnoDB: Waiting for the background threads to start 190411 15:58:03 Percona XtraDB (http://www.percona.com) 5.5.59-MariaDB-38.11 started; log sequence number 8622831 190411 15:58:03 [Note] Plugin 'FEEDBACK' is disabled. 190411 15:58:03 [Note] Server socket created on IP: '0.0.0.0'. 190411 15:58:03 [Note] Event Scheduler: Loaded 0 events 190411 15:58:03 [Note] /usr/libexec/mysqld: ready for connections. Version: '5.5.60-MariaDB' socket: '/data/mysql/mysql.sock' port: 3306 MariaDB Server 190418 13:44:19 InnoDB: Assertion failure in thread 139985383655168 in file fut0lst.ic line 83 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: http://dev.mysql.com/doc/refman/5.5/en/forcing-innodb-recovery.html InnoDB: about forcing recovery. 190418 13:44:19 [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 http://kb.askmonty.org/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: 5.5.60-MariaDB key_buffer_size=134217728 read_buffer_size=131072 max_used_connections=7 max_threads=153 thread_count=1 It is possible that mysqld could use up to key_buffer_size + (read_buffer_size + sort_buffer_size)*max_threads = 466718 K bytes of memory Hope that's ok; if not, decrease some variables in the equation. Thread pointer: 0x561556548a60 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 = 0x7f50e310fd80 thread_stack 0x48000 /usr/libexec/mysqld(my_print_stacktrace+0x3d)[0x561552d40cbd] /usr/libexec/mysqld(handle_fatal_signal+0x515)[0x5615529554a5] sigaction.c:0(__restore_rt)[0x7f51005425d0] :0(__GI_raise)[0x7f50fec6c207] :0(__GI_abort)[0x7f50fec6d8f8] /usr/libexec/mysqld(+0x2d73b7)[0x5615527883b7] /usr/libexec/mysqld(+0x6f87d0)[0x561552ba97d0] /usr/libexec/mysqld(+0x657ade)[0x561552b08ade] /usr/libexec/mysqld(+0x671153)[0x561552b22153] /usr/libexec/mysqld(+0x666faf)[0x561552b17faf] /usr/libexec/mysqld(+0x668d94)[0x561552b19d94] /usr/libexec/mysqld(+0x66a6c7)[0x561552b1b6c7] /usr/libexec/mysqld(+0x60a5a0)[0x561552abb5a0] /usr/libexec/mysqld(+0x60b54b)[0x561552abc54b] /usr/libexec/mysqld(_Z19ha_commit_one_phaseP3THDb+0x80)[0x561552957ac0] /usr/libexec/mysqld(_Z15ha_commit_transP3THDb+0x356)[0x561552958236] /usr/libexec/mysqld(_Z17trans_commit_stmtP3THD+0x1b)[0x5615528eb3bb] /usr/libexec/mysqld(_Z21mysql_execute_commandP3THD+0x3dc)[0x5615528239ec] /usr/libexec/mysqld(_Z11mysql_parseP3THDPcjP12Parser_state+0x125)[0x56155282a445] /usr/libexec/mysqld(_Z16dispatch_command19enum_server_commandP3THDPcj+0x1750)[0x56155282c4a0] /usr/libexec/mysqld(_Z24do_handle_one_connectionP3THD+0x1c2)[0x5615528dea22] /usr/libexec/mysqld(handle_one_connection+0x4a)[0x5615528deaca] pthread_create.c:0(start_thread)[0x7f510053add5] /lib64/libc.so.6(clone+0x6d)[0x7f50fed33ead] Trying to get some variables. Some pointers may be invalid and cause the dump to abort. Query (0x7f50bc004c18): UPDATE `users` SET `lastActivity`='2019-04-18 11:44:19' WHERE `id`='2' Connection ID (thread ID): 570 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=on,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=off,table_elimination=on,extended_keys=off 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. 190418 13:44:19 mysqld_safe Number of processes running now: 0 190418 13:44:19 mysqld_safe mysqld restarted 190418 13:44:19 [Note] /usr/libexec/mysqld (mysqld 5.5.60-MariaDB) starting as process 19599 ... 190418 13:44:19 InnoDB: The InnoDB memory heap is disabled 190418 13:44:19 InnoDB: Mutexes and rw_locks use GCC atomic builtins 190418 13:44:19 InnoDB: Compressed tables use zlib 1.2.7 190418 13:44:19 InnoDB: Using Linux native AIO 190418 13:44:19 InnoDB: Initializing buffer pool, size = 128.0M 190418 13:44:19 InnoDB: Completed initialization of buffer pool 190418 13:44:19 InnoDB: highest supported file format is Barracuda. InnoDB: The log sequence number in ibdata files does not match InnoDB: the log sequence number in the ib_logfiles! InnoDB: Restoring possible half-written data pages from the doublewrite buffer... 190418 13:44:19 InnoDB: Waiting for the background threads to start 190418 13:44:20 Percona XtraDB (http://www.percona.com) 5.5.59-MariaDB-38.11 started; log sequence number 8678474 190418 13:44:20 [Note] Plugin 'FEEDBACK' is disabled. 190418 13:44:20 [Note] Server socket created on IP: '0.0.0.0'. 190418 13:44:20 [Note] Event Scheduler: Loaded 0 events 190418 13:44:20 [Note] /usr/libexec/mysqld: ready for connections. Version: '5.5.60-MariaDB' socket: '/data/mysql/mysql.sock' port: 3306 MariaDB Server 190423 9:05:20 InnoDB: Assertion failure in thread 140418387945216 in file fut0lst.ic line 83 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: http://dev.mysql.com/doc/refman/5.5/en/forcing-innodb-recovery.html InnoDB: about forcing recovery. 190423 9:05:21 [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 http://kb.askmonty.org/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: 5.5.60-MariaDB key_buffer_size=134217728 read_buffer_size=131072 max_used_connections=7 max_threads=153 thread_count=1 It is possible that mysqld could use up to key_buffer_size + (read_buffer_size + sort_buffer_size)*max_threads = 466718 K bytes of memory Hope that's ok; if not, decrease some variables in the equation. Thread pointer: 0x55a033b2a460 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 = 0x7fb5b4221d80 thread_stack 0x48000 /usr/libexec/mysqld(my_print_stacktrace+0x3d)[0x55a031c01cbd] /usr/libexec/mysqld(handle_fatal_signal+0x515)[0x55a0318164a5] sigaction.c:0(__restore_rt)[0x7fb5b8fab5d0] :0(__GI_raise)[0x7fb5b76d5207] :0(__GI_abort)[0x7fb5b76d68f8] /usr/libexec/mysqld(+0x2d73b7)[0x55a0316493b7] /usr/libexec/mysqld(+0x6f87d0)[0x55a031a6a7d0] /usr/libexec/mysqld(+0x657ade)[0x55a0319c9ade] /usr/libexec/mysqld(+0x671153)[0x55a0319e3153] /usr/libexec/mysqld(+0x666faf)[0x55a0319d8faf] /usr/libexec/mysqld(+0x668d94)[0x55a0319dad94] /usr/libexec/mysqld(+0x66a6c7)[0x55a0319dc6c7] /usr/libexec/mysqld(+0x60a5a0)[0x55a03197c5a0] /usr/libexec/mysqld(+0x60b54b)[0x55a03197d54b] /usr/libexec/mysqld(_Z19ha_commit_one_phaseP3THDb+0x80)[0x55a031818ac0] /usr/libexec/mysqld(_Z15ha_commit_transP3THDb+0x356)[0x55a031819236] /usr/libexec/mysqld(_Z17trans_commit_stmtP3THD+0x1b)[0x55a0317ac3bb] /usr/libexec/mysqld(_Z21mysql_execute_commandP3THD+0x3dc)[0x55a0316e49ec] /usr/libexec/mysqld(_Z11mysql_parseP3THDPcjP12Parser_state+0x125)[0x55a0316eb445] /usr/libexec/mysqld(_Z16dispatch_command19enum_server_commandP3THDPcj+0x1750)[0x55a0316ed4a0] /usr/libexec/mysqld(_Z24do_handle_one_connectionP3THD+0x1c2)[0x55a03179fa22] /usr/libexec/mysqld(handle_one_connection+0x4a)[0x55a03179faca] pthread_create.c:0(start_thread)[0x7fb5b8fa3dd5] /lib64/libc.so.6(clone+0x6d)[0x7fb5b779cead] Trying to get some variables. Some pointers may be invalid and cause the dump to abort. Query (0x7fb56c01b968): UPDATE `users` SET `lastLogin`='2019-04-23 07:05:20' WHERE `id`='3' Connection ID (thread ID): 213 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=on,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=off,table_elimination=on,extended_keys=off 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. 190423 09:05:21 mysqld_safe Number of processes running now: 0 190423 09:05:21 mysqld_safe mysqld restarted 190423 9:05:21 [Note] /usr/libexec/mysqld (mysqld 5.5.60-MariaDB) starting as process 4878 ... 190423 9:05:21 InnoDB: The InnoDB memory heap is disabled 190423 9:05:21 InnoDB: Mutexes and rw_locks use GCC atomic builtins 190423 9:05:21 InnoDB: Compressed tables use zlib 1.2.7 190423 9:05:21 InnoDB: Using Linux native AIO 190423 9:05:21 InnoDB: Initializing buffer pool, size = 128.0M 190423 9:05:21 InnoDB: Completed initialization of buffer pool 190423 9:05:21 InnoDB: highest supported file format is Barracuda. 190423 9:05:21 InnoDB: Starting crash recovery from checkpoint LSN=8706756 InnoDB: Restoring possible half-written data pages from the doublewrite buffer... 190423 9:05:21 InnoDB: Starting final batch to recover 1 pages from redo log 190423 9:05:21 InnoDB: Waiting for the background threads to start 190423 9:05:22 Percona XtraDB (http://www.percona.com) 5.5.59-MariaDB-38.11 started; log sequence number 8706963 190423 9:05:22 [Note] Plugin 'FEEDBACK' is disabled. 190423 9:05:22 [Note] Server socket created on IP: '0.0.0.0'. 190423 9:05:22 [Note] Event Scheduler: Loaded 0 events 190423 9:05:22 [Note] /usr/libexec/mysqld: ready for connections. Version: '5.5.60-MariaDB' socket: '/data/mysql/mysql.sock' port: 3306 MariaDB Server 190423 10:10:28 InnoDB: Assertion failure in thread 140708834088704 in file fut0lst.ic line 83 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: http://dev.mysql.com/doc/refman/5.5/en/forcing-innodb-recovery.html InnoDB: about forcing recovery. 190423 10:10:28 [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 http://kb.askmonty.org/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: 5.5.60-MariaDB key_buffer_size=134217728 read_buffer_size=131072 max_used_connections=8 max_threads=153 thread_count=1 It is possible that mysqld could use up to key_buffer_size + (read_buffer_size + sort_buffer_size)*max_threads = 466718 K bytes of memory Hope that's ok; if not, decrease some variables in the equation. Thread pointer: 0x55f724fee060 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 = 0x7ff954128d80 thread_stack 0x48000 /usr/libexec/mysqld(my_print_stacktrace+0x3d)[0x55f7230cbcbd] /usr/libexec/mysqld(handle_fatal_signal+0x515)[0x55f722ce04a5] sigaction.c:0(__restore_rt)[0x7ff95a6545d0] :0(__GI_raise)[0x7ff958d7e207] :0(__GI_abort)[0x7ff958d7f8f8] /usr/libexec/mysqld(+0x2d73b7)[0x55f722b133b7] /usr/libexec/mysqld(+0x6f87d0)[0x55f722f347d0] /usr/libexec/mysqld(+0x657ade)[0x55f722e93ade] /usr/libexec/mysqld(+0x671153)[0x55f722ead153] /usr/libexec/mysqld(+0x666faf)[0x55f722ea2faf] /usr/libexec/mysqld(+0x668d94)[0x55f722ea4d94] /usr/libexec/mysqld(+0x66a6c7)[0x55f722ea66c7] /usr/libexec/mysqld(+0x60a5a0)[0x55f722e465a0] /usr/libexec/mysqld(+0x60b54b)[0x55f722e4754b] /usr/libexec/mysqld(_Z19ha_commit_one_phaseP3THDb+0x80)[0x55f722ce2ac0] /usr/libexec/mysqld(_Z15ha_commit_transP3THDb+0x356)[0x55f722ce3236] /usr/libexec/mysqld(_Z17trans_commit_stmtP3THD+0x1b)[0x55f722c763bb] /usr/libexec/mysqld(_Z21mysql_execute_commandP3THD+0x3dc)[0x55f722bae9ec] /usr/libexec/mysqld(_Z11mysql_parseP3THDPcjP12Parser_state+0x125)[0x55f722bb5445] /usr/libexec/mysqld(_Z16dispatch_command19enum_server_commandP3THDPcj+0x1750)[0x55f722bb74a0] /usr/libexec/mysqld(_Z24do_handle_one_connectionP3THD+0x1c2)[0x55f722c69a22] /usr/libexec/mysqld(handle_one_connection+0x4a)[0x55f722c69aca] pthread_create.c:0(start_thread)[0x7ff95a64cdd5] /lib64/libc.so.6(clone+0x6d)[0x7ff958e45ead] Trying to get some variables. Some pointers may be invalid and cause the dump to abort. Query (0x7ff91c04fb48): UPDATE `users` SET `lastActivity`='2019-04-23 08:10:28' WHERE `id`='1' Connection ID (thread ID): 399 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=on,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=off,table_elimination=on,extended_keys=off 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. 190423 10:10:29 mysqld_safe Number of processes running now: 0 190423 10:10:29 mysqld_safe mysqld restarted 190423 10:10:29 [Note] /usr/libexec/mysqld (mysqld 5.5.60-MariaDB) starting as process 6952 ... 190423 10:10:29 InnoDB: The InnoDB memory heap is disabled 190423 10:10:29 InnoDB: Mutexes and rw_locks use GCC atomic builtins 190423 10:10:29 InnoDB: Compressed tables use zlib 1.2.7 190423 10:10:29 InnoDB: Using Linux native AIO 190423 10:10:29 InnoDB: Initializing buffer pool, size = 128.0M 190423 10:10:29 InnoDB: Completed initialization of buffer pool 190423 10:10:29 InnoDB: highest supported file format is Barracuda. 190423 10:10:29 InnoDB: Starting crash recovery from checkpoint LSN=9618919 InnoDB: Restoring possible half-written data pages from the doublewrite buffer... 190423 10:10:29 InnoDB: Starting final batch to recover 1 pages from redo log 190423 10:10:29 InnoDB: Waiting for the background threads to start 190423 10:10:30 Percona XtraDB (http://www.percona.com) 5.5.59-MariaDB-38.11 started; log sequence number 9619498 190423 10:10:30 [Note] Plugin 'FEEDBACK' is disabled. 190423 10:10:30 [Note] Server socket created on IP: '0.0.0.0'. 190423 10:10:30 [Note] Event Scheduler: Loaded 0 events 190423 10:10:30 [Note] /usr/libexec/mysqld: ready for connections. Version: '5.5.60-MariaDB' socket: '/data/mysql/mysql.sock' port: 3306 MariaDB Server 190423 11:10:29 InnoDB: Assertion failure in thread 139988892821248 in file fut0lst.ic line 83 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: http://dev.mysql.com/doc/refman/5.5/en/forcing-innodb-recovery.html InnoDB: about forcing recovery. 190423 11:10:29 [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 http://kb.askmonty.org/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: 5.5.60-MariaDB key_buffer_size=134217728 read_buffer_size=131072 max_used_connections=3 max_threads=153 thread_count=1 It is possible that mysqld could use up to key_buffer_size + (read_buffer_size + sort_buffer_size)*max_threads = 466718 K bytes of memory Hope that's ok; if not, decrease some variables in the equation. Thread pointer: 0x562b4b0db440 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 = 0x7f51b43a9d80 thread_stack 0x48000 /usr/libexec/mysqld(my_print_stacktrace+0x3d)[0x562b47cd5cbd] /usr/libexec/mysqld(handle_fatal_signal+0x515)[0x562b478ea4a5] sigaction.c:0(__restore_rt)[0x7f51b88545d0] :0(__GI_raise)[0x7f51b6f7e207] :0(__GI_abort)[0x7f51b6f7f8f8] /usr/libexec/mysqld(+0x2d73b7)[0x562b4771d3b7] /usr/libexec/mysqld(+0x6f87d0)[0x562b47b3e7d0] /usr/libexec/mysqld(+0x657ade)[0x562b47a9dade] /usr/libexec/mysqld(+0x671153)[0x562b47ab7153] /usr/libexec/mysqld(+0x666faf)[0x562b47aacfaf] /usr/libexec/mysqld(+0x668d94)[0x562b47aaed94] /usr/libexec/mysqld(+0x66a6c7)[0x562b47ab06c7] /usr/libexec/mysqld(+0x60a5a0)[0x562b47a505a0] /usr/libexec/mysqld(+0x60b54b)[0x562b47a5154b] /usr/libexec/mysqld(_Z19ha_commit_one_phaseP3THDb+0x80)[0x562b478ecac0] /usr/libexec/mysqld(_Z15ha_commit_transP3THDb+0x356)[0x562b478ed236] /usr/libexec/mysqld(_Z17trans_commit_stmtP3THD+0x1b)[0x562b478803bb] /usr/libexec/mysqld(_Z21mysql_execute_commandP3THD+0x3dc)[0x562b477b89ec] /usr/libexec/mysqld(_Z11mysql_parseP3THDPcjP12Parser_state+0x125)[0x562b477bf445] /usr/libexec/mysqld(_Z16dispatch_command19enum_server_commandP3THDPcj+0x1750)[0x562b477c14a0] /usr/libexec/mysqld(_Z24do_handle_one_connectionP3THD+0x1c2)[0x562b47873a22] /usr/libexec/mysqld(handle_one_connection+0x4a)[0x562b47873aca] pthread_create.c:0(start_thread)[0x7f51b884cdd5] /lib64/libc.so.6(clone+0x6d)[0x7f51b7045ead] Trying to get some variables. Some pointers may be invalid and cause the dump to abort. Query (0x7f5174004c18): UPDATE `users` SET `lastActivity`='2019-04-23 09:10:29' WHERE `id`='1' Connection ID (thread ID): 65 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=on,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=off,table_elimination=on,extended_keys=off 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. 190423 11:10:30 mysqld_safe Number of processes running now: 0 190423 11:10:30 mysqld_safe mysqld restarted 190423 11:10:30 [Note] /usr/libexec/mysqld (mysqld 5.5.60-MariaDB) starting as process 9440 ... 190423 11:10:30 InnoDB: The InnoDB memory heap is disabled 190423 11:10:30 InnoDB: Mutexes and rw_locks use GCC atomic builtins 190423 11:10:30 InnoDB: Compressed tables use zlib 1.2.7 190423 11:10:30 InnoDB: Using Linux native AIO 190423 11:10:30 InnoDB: Initializing buffer pool, size = 128.0M 190423 11:10:30 InnoDB: Completed initialization of buffer pool 190423 11:10:30 InnoDB: highest supported file format is Barracuda. InnoDB: The log sequence number in ibdata files does not match InnoDB: the log sequence number in the ib_logfiles! InnoDB: Restoring possible half-written data pages from the doublewrite buffer... 190423 11:10:30 InnoDB: Waiting for the background threads to start 190423 11:10:31 Percona XtraDB (http://www.percona.com) 5.5.59-MariaDB-38.11 started; log sequence number 9909444 190423 11:10:31 [Note] Plugin 'FEEDBACK' is disabled. 190423 11:10:31 [Note] Server socket created on IP: '0.0.0.0'. 190423 11:10:31 [Note] Event Scheduler: Loaded 0 events 190423 11:10:31 [Note] /usr/libexec/mysqld: ready for connections. Version: '5.5.60-MariaDB' socket: '/data/mysql/mysql.sock' port: 3306 MariaDB Server 190423 11:58:44 InnoDB: Assertion failure in thread 140284399539968 in file fut0lst.ic line 83 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: http://dev.mysql.com/doc/refman/5.5/en/forcing-innodb-recovery.html InnoDB: about forcing recovery. 190423 11:58:44 [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 http://kb.askmonty.org/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: 5.5.60-MariaDB key_buffer_size=134217728 read_buffer_size=131072 max_used_connections=7 max_threads=153 thread_count=1 It is possible that mysqld could use up to key_buffer_size + (read_buffer_size + sort_buffer_size)*max_threads = 466718 K bytes of memory Hope that's ok; if not, decrease some variables in the equation. Thread pointer: 0x55e681a42510 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 = 0x7f9681cd4d80 thread_stack 0x48000 /usr/libexec/mysqld(my_print_stacktrace+0x3d)[0x55e67eb3fcbd] /usr/libexec/mysqld(handle_fatal_signal+0x515)[0x55e67e7544a5] sigaction.c:0(__restore_rt)[0x7f96a30945d0] :0(__GI_raise)[0x7f96a17be207] :0(__GI_abort)[0x7f96a17bf8f8] /usr/libexec/mysqld(+0x2d73b7)[0x55e67e5873b7] /usr/libexec/mysqld(+0x6f87d0)[0x55e67e9a87d0] /usr/libexec/mysqld(+0x657ade)[0x55e67e907ade] /usr/libexec/mysqld(+0x671153)[0x55e67e921153] /usr/libexec/mysqld(+0x666faf)[0x55e67e916faf] /usr/libexec/mysqld(+0x668d94)[0x55e67e918d94] /usr/libexec/mysqld(+0x66a6c7)[0x55e67e91a6c7] /usr/libexec/mysqld(+0x60a5a0)[0x55e67e8ba5a0] /usr/libexec/mysqld(+0x60b54b)[0x55e67e8bb54b] /usr/libexec/mysqld(_Z19ha_commit_one_phaseP3THDb+0x80)[0x55e67e756ac0] /usr/libexec/mysqld(_Z15ha_commit_transP3THDb+0x356)[0x55e67e757236] /usr/libexec/mysqld(_Z17trans_commit_stmtP3THD+0x1b)[0x55e67e6ea3bb] /usr/libexec/mysqld(_Z21mysql_execute_commandP3THD+0x3dc)[0x55e67e6229ec] /usr/libexec/mysqld(_Z11mysql_parseP3THDPcjP12Parser_state+0x125)[0x55e67e629445] /usr/libexec/mysqld(_Z16dispatch_command19enum_server_commandP3THDPcj+0x1750)[0x55e67e62b4a0] /usr/libexec/mysqld(_Z24do_handle_one_connectionP3THD+0x1c2)[0x55e67e6dda22] /usr/libexec/mysqld(handle_one_connection+0x4a)[0x55e67e6ddaca] pthread_create.c:0(start_thread)[0x7f96a308cdd5] /lib64/libc.so.6(clone+0x6d)[0x7f96a1885ead] Trying to get some variables. Some pointers may be invalid and cause the dump to abort. Query (0x7f9660057658): UPDATE `users` SET `lastLogin`='2019-04-23 09:58:44' WHERE `id`='3' Connection ID (thread ID): 73 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=on,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=off,table_elimination=on,extended_keys=off 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. 190423 11:58:44 mysqld_safe Number of processes running now: 0 190423 11:58:44 mysqld_safe mysqld restarted 190423 11:58:44 [Note] /usr/libexec/mysqld (mysqld 5.5.60-MariaDB) starting as process 10962 ... 190423 11:58:44 InnoDB: The InnoDB memory heap is disabled 190423 11:58:44 InnoDB: Mutexes and rw_locks use GCC atomic builtins 190423 11:58:44 InnoDB: Compressed tables use zlib 1.2.7 190423 11:58:44 InnoDB: Using Linux native AIO 190423 11:58:44 InnoDB: Initializing buffer pool, size = 128.0M 190423 11:58:44 InnoDB: Completed initialization of buffer pool 190423 11:58:44 InnoDB: highest supported file format is Barracuda. 190423 11:58:44 InnoDB: Starting crash recovery from checkpoint LSN=9922851 InnoDB: Restoring possible half-written data pages from the doublewrite buffer... 190423 11:58:44 InnoDB: Starting final batch to recover 1 pages from redo log 190423 11:58:44 InnoDB: Waiting for the background threads to start 190423 11:58:45 Percona XtraDB (http://www.percona.com) 5.5.59-MariaDB-38.11 started; log sequence number 9923058 190423 11:58:45 [Note] Plugin 'FEEDBACK' is disabled. 190423 11:58:45 [Note] Server socket created on IP: '0.0.0.0'. 190423 11:58:45 [Note] Event Scheduler: Loaded 0 events 190423 11:58:45 [Note] /usr/libexec/mysqld: ready for connections. Version: '5.5.60-MariaDB' socket: '/data/mysql/mysql.sock' port: 3306 MariaDB Server 190423 15:44:10 InnoDB: Assertion failure in thread 140669910898432 in file fut0lst.ic line 83 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: http://dev.mysql.com/doc/refman/5.5/en/forcing-innodb-recovery.html InnoDB: about forcing recovery. 190423 15:44:10 [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 http://kb.askmonty.org/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: 5.5.60-MariaDB key_buffer_size=134217728 read_buffer_size=131072 max_used_connections=7 max_threads=153 thread_count=1 It is possible that mysqld could use up to key_buffer_size + (read_buffer_size + sort_buffer_size)*max_threads = 466718 K bytes of memory Hope that's ok; if not, decrease some variables in the equation. Thread pointer: 0x55ae9815a430 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 = 0x7ff04411cd80 thread_stack 0x48000 /usr/libexec/mysqld(my_print_stacktrace+0x3d)[0x55ae94ea0cbd] /usr/libexec/mysqld(handle_fatal_signal+0x515)[0x55ae94ab54a5] sigaction.c:0(__restore_rt)[0x7ff048ea65d0] :0(__GI_raise)[0x7ff0475d0207] :0(__GI_abort)[0x7ff0475d18f8] /usr/libexec/mysqld(+0x2d73b7)[0x55ae948e83b7] /usr/libexec/mysqld(+0x6f87d0)[0x55ae94d097d0] /usr/libexec/mysqld(+0x657ade)[0x55ae94c68ade] /usr/libexec/mysqld(+0x671153)[0x55ae94c82153] /usr/libexec/mysqld(+0x666faf)[0x55ae94c77faf] /usr/libexec/mysqld(+0x668d94)[0x55ae94c79d94] /usr/libexec/mysqld(+0x66a6c7)[0x55ae94c7b6c7] /usr/libexec/mysqld(+0x60a5a0)[0x55ae94c1b5a0] /usr/libexec/mysqld(+0x60b54b)[0x55ae94c1c54b] /usr/libexec/mysqld(_Z19ha_commit_one_phaseP3THDb+0x80)[0x55ae94ab7ac0] /usr/libexec/mysqld(_Z15ha_commit_transP3THDb+0x356)[0x55ae94ab8236] /usr/libexec/mysqld(_Z17trans_commit_stmtP3THD+0x1b)[0x55ae94a4b3bb] /usr/libexec/mysqld(_Z21mysql_execute_commandP3THD+0x3dc)[0x55ae949839ec] /usr/libexec/mysqld(_Z11mysql_parseP3THDPcjP12Parser_state+0x125)[0x55ae9498a445] /usr/libexec/mysqld(_Z16dispatch_command19enum_server_commandP3THDPcj+0x1750)[0x55ae9498c4a0] /usr/libexec/mysqld(_Z24do_handle_one_connectionP3THD+0x1c2)[0x55ae94a3ea22] /usr/libexec/mysqld(handle_one_connection+0x4a)[0x55ae94a3eaca] pthread_create.c:0(start_thread)[0x7ff048e9edd5] /lib64/libc.so.6(clone+0x6d)[0x7ff047697ead] Trying to get some variables. Some pointers may be invalid and cause the dump to abort. Query (0x7ff00c004c18): UPDATE `users` SET `lastActivity`='2019-04-23 13:44:10' WHERE `id`='1' Connection ID (thread ID): 1059 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=on,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=off,table_elimination=on,extended_keys=off 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. 190423 15:44:10 mysqld_safe Number of processes running now: 0 190423 15:44:10 mysqld_safe mysqld restarted 190423 15:44:10 [Note] /usr/libexec/mysqld (mysqld 5.5.60-MariaDB) starting as process 17752 ... 190423 15:44:10 InnoDB: The InnoDB memory heap is disabled 190423 15:44:10 InnoDB: Mutexes and rw_locks use GCC atomic builtins 190423 15:44:10 InnoDB: Compressed tables use zlib 1.2.7 190423 15:44:10 InnoDB: Using Linux native AIO 190423 15:44:10 InnoDB: Initializing buffer pool, size = 128.0M 190423 15:44:10 InnoDB: Completed initialization of buffer pool 190423 15:44:10 InnoDB: highest supported file format is Barracuda. InnoDB: The log sequence number in ibdata files does not match InnoDB: the log sequence number in the ib_logfiles! InnoDB: Restoring possible half-written data pages from the doublewrite buffer... 190423 15:44:10 InnoDB: Waiting for the background threads to start 190423 15:44:11 Percona XtraDB (http://www.percona.com) 5.5.59-MariaDB-38.11 started; log sequence number 16102020 190423 15:44:11 [Note] Plugin 'FEEDBACK' is disabled. 190423 15:44:11 [Note] Server socket created on IP: '0.0.0.0'. 190423 15:44:11 [Note] Event Scheduler: Loaded 0 events 190423 15:44:11 [Note] /usr/libexec/mysqld: ready for connections. Version: '5.5.60-MariaDB' socket: '/data/mysql/mysql.sock' port: 3306 MariaDB Server 190423 15:54:14 InnoDB: Assertion failure in thread 139958423582464 in file fut0lst.ic line 83 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: http://dev.mysql.com/doc/refman/5.5/en/forcing-innodb-recovery.html InnoDB: about forcing recovery. 190423 15:54:14 [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 http://kb.askmonty.org/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: 5.5.60-MariaDB key_buffer_size=134217728 read_buffer_size=131072 max_used_connections=3 max_threads=153 thread_count=1 It is possible that mysqld could use up to key_buffer_size + (read_buffer_size + sort_buffer_size)*max_threads = 466718 K bytes of memory Hope that's ok; if not, decrease some variables in the equation. Thread pointer: 0x5562e9530140 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 = 0x7f4a9c1eed80 thread_stack 0x48000 /usr/libexec/mysqld(my_print_stacktrace+0x3d)[0x5562e5c8ccbd] /usr/libexec/mysqld(handle_fatal_signal+0x515)[0x5562e58a14a5] sigaction.c:0(__restore_rt)[0x7f4aa00ab5d0] :0(__GI_raise)[0x7f4a9e7d5207] :0(__GI_abort)[0x7f4a9e7d68f8] /usr/libexec/mysqld(+0x2d73b7)[0x5562e56d43b7] /usr/libexec/mysqld(+0x6f87d0)[0x5562e5af57d0] /usr/libexec/mysqld(+0x657ade)[0x5562e5a54ade] /usr/libexec/mysqld(+0x671153)[0x5562e5a6e153] /usr/libexec/mysqld(+0x666faf)[0x5562e5a63faf] /usr/libexec/mysqld(+0x668d94)[0x5562e5a65d94] /usr/libexec/mysqld(+0x66a6c7)[0x5562e5a676c7] /usr/libexec/mysqld(+0x60a5a0)[0x5562e5a075a0] /usr/libexec/mysqld(+0x60b54b)[0x5562e5a0854b] /usr/libexec/mysqld(_Z19ha_commit_one_phaseP3THDb+0x80)[0x5562e58a3ac0] /usr/libexec/mysqld(_Z15ha_commit_transP3THDb+0x356)[0x5562e58a4236] /usr/libexec/mysqld(_Z17trans_commit_stmtP3THD+0x1b)[0x5562e58373bb] /usr/libexec/mysqld(_Z21mysql_execute_commandP3THD+0x3dc)[0x5562e576f9ec] /usr/libexec/mysqld(_Z11mysql_parseP3THDPcjP12Parser_state+0x125)[0x5562e5776445] /usr/libexec/mysqld(_Z16dispatch_command19enum_server_commandP3THDPcj+0x1750)[0x5562e57784a0] /usr/libexec/mysqld(_Z24do_handle_one_connectionP3THD+0x1c2)[0x5562e582aa22] /usr/libexec/mysqld(handle_one_connection+0x4a)[0x5562e582aaca] pthread_create.c:0(start_thread)[0x7f4aa00a3dd5] /lib64/libc.so.6(clone+0x6d)[0x7f4a9e89cead] Trying to get some variables. Some pointers may be invalid and cause the dump to abort. Query (0x7f4a600379d8): UPDATE `ipaddresses` SET `lastSeen`='2019-04-23 13:54:14' WHERE `id`='5866' Connection ID (thread ID): 174 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=on,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=off,table_elimination=on,extended_keys=off 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. 190423 15:54:14 mysqld_safe Number of processes running now: 0 190423 15:54:14 mysqld_safe mysqld restarted 190423 15:54:14 [Note] /usr/libexec/mysqld (mysqld 5.5.60-MariaDB) starting as process 19505 ... 190423 15:54:14 InnoDB: The InnoDB memory heap is disabled 190423 15:54:14 InnoDB: Mutexes and rw_locks use GCC atomic builtins 190423 15:54:14 InnoDB: Compressed tables use zlib 1.2.7 190423 15:54:14 InnoDB: Using Linux native AIO 190423 15:54:14 InnoDB: Initializing buffer pool, size = 128.0M 190423 15:54:14 InnoDB: Completed initialization of buffer pool 190423 15:54:14 InnoDB: highest supported file format is Barracuda. 190423 15:54:14 InnoDB: Starting crash recovery from checkpoint LSN=16431429 InnoDB: Restoring possible half-written data pages from the doublewrite buffer... 190423 15:54:14 InnoDB: Starting final batch to recover 4 pages from redo log 190423 15:54:15 InnoDB: Waiting for the background threads to start 190423 15:54:16 Percona XtraDB (http://www.percona.com) 5.5.59-MariaDB-38.11 started; log sequence number 16464526 190423 15:54:16 [Note] Plugin 'FEEDBACK' is disabled. 190423 15:54:16 [Note] Server socket created on IP: '0.0.0.0'. 190423 15:54:16 [Note] Event Scheduler: Loaded 0 events 190423 15:54:16 [Note] /usr/libexec/mysqld: ready for connections. Version: '5.5.60-MariaDB' socket: '/data/mysql/mysql.sock' port: 3306 MariaDB Server 190423 15:54:22 InnoDB: Assertion failure in thread 140647431100160 in file fut0lst.ic line 83 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: http://dev.mysql.com/doc/refman/5.5/en/forcing-innodb-recovery.html InnoDB: about forcing recovery. 190423 15:54:22 [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 http://kb.askmonty.org/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: 5.5.60-MariaDB key_buffer_size=134217728 read_buffer_size=131072 max_used_connections=3 max_threads=153 thread_count=1 It is possible that mysqld could use up to key_buffer_size + (read_buffer_size + sort_buffer_size)*max_threads = 466718 K bytes of memory Hope that's ok; if not, decrease some variables in the equation. Thread pointer: 0x55aaba28c650 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 = 0x7feb082b4d80 thread_stack 0x48000 /usr/libexec/mysqld(my_print_stacktrace+0x3d)[0x55aab73a4cbd] /usr/libexec/mysqld(handle_fatal_signal+0x515)[0x55aab6fb94a5] sigaction.c:0(__restore_rt)[0x7feb0c9bc5d0] :0(__GI_raise)[0x7feb0b0e6207] :0(__GI_abort)[0x7feb0b0e78f8] /usr/libexec/mysqld(+0x2d73b7)[0x55aab6dec3b7] /usr/libexec/mysqld(+0x6f87d0)[0x55aab720d7d0] /usr/libexec/mysqld(+0x657ade)[0x55aab716cade] /usr/libexec/mysqld(+0x671153)[0x55aab7186153] /usr/libexec/mysqld(+0x666faf)[0x55aab717bfaf] /usr/libexec/mysqld(+0x668d94)[0x55aab717dd94] /usr/libexec/mysqld(+0x66a6c7)[0x55aab717f6c7] /usr/libexec/mysqld(+0x60a5a0)[0x55aab711f5a0] /usr/libexec/mysqld(+0x60b54b)[0x55aab712054b] /usr/libexec/mysqld(_Z19ha_commit_one_phaseP3THDb+0x80)[0x55aab6fbbac0] /usr/libexec/mysqld(_Z15ha_commit_transP3THDb+0x356)[0x55aab6fbc236] /usr/libexec/mysqld(_Z17trans_commit_stmtP3THD+0x1b)[0x55aab6f4f3bb] /usr/libexec/mysqld(_Z21mysql_execute_commandP3THD+0x3dc)[0x55aab6e879ec] /usr/libexec/mysqld(_Z11mysql_parseP3THDPcjP12Parser_state+0x125)[0x55aab6e8e445] /usr/libexec/mysqld(_Z16dispatch_command19enum_server_commandP3THDPcj+0x1750)[0x55aab6e904a0] /usr/libexec/mysqld(_Z24do_handle_one_connectionP3THD+0x1c2)[0x55aab6f42a22] /usr/libexec/mysqld(handle_one_connection+0x4a)[0x55aab6f42aca] pthread_create.c:0(start_thread)[0x7feb0c9b4dd5] /lib64/libc.so.6(clone+0x6d)[0x7feb0b1adead] Trying to get some variables. Some pointers may be invalid and cause the dump to abort. Query (0x7feac4004c38): UPDATE `ipaddresses` SET `lastSeen`='2019-04-23 13:54:22' WHERE `id`='6767' Connection ID (thread ID): 2 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=on,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=off,table_elimination=on,extended_keys=off 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. 190423 15:54:22 mysqld_safe Number of processes running now: 0 190423 15:54:22 mysqld_safe mysqld restarted 190423 15:54:22 [Note] /usr/libexec/mysqld (mysqld 5.5.60-MariaDB) starting as process 20116 ... 190423 15:54:22 InnoDB: The InnoDB memory heap is disabled 190423 15:54:22 InnoDB: Mutexes and rw_locks use GCC atomic builtins 190423 15:54:22 InnoDB: Compressed tables use zlib 1.2.7 190423 15:54:22 InnoDB: Using Linux native AIO 190423 15:54:22 InnoDB: Initializing buffer pool, size = 128.0M 190423 15:54:22 InnoDB: Completed initialization of buffer pool 190423 15:54:22 InnoDB: highest supported file format is Barracuda. 190423 15:54:22 InnoDB: Starting crash recovery from checkpoint LSN=16464526 InnoDB: Restoring possible half-written data pages from the doublewrite buffer... 190423 15:54:22 InnoDB: Starting final batch to recover 4 pages from redo log 190423 15:54:23 InnoDB: Waiting for the background threads to start 190423 15:54:24 Percona XtraDB (http://www.percona.com) 5.5.59-MariaDB-38.11 started; log sequence number 16479099 190423 15:54:24 [Note] Plugin 'FEEDBACK' is disabled. 190423 15:54:24 [Note] Server socket created on IP: '0.0.0.0'. 190423 15:54:24 [Note] Event Scheduler: Loaded 0 events 190423 15:54:24 [Note] /usr/libexec/mysqld: ready for connections. Version: '5.5.60-MariaDB' socket: '/data/mysql/mysql.sock' port: 3306 MariaDB Server 190423 15:55:10 InnoDB: Assertion failure in thread 140027678344960 in file fut0lst.ic line 83 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: http://dev.mysql.com/doc/refman/5.5/en/forcing-innodb-recovery.html InnoDB: about forcing recovery. 190423 15:55:10 [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 http://kb.askmonty.org/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: 5.5.60-MariaDB key_buffer_size=134217728 read_buffer_size=131072 max_used_connections=3 max_threads=153 thread_count=1 It is possible that mysqld could use up to key_buffer_size + (read_buffer_size + sort_buffer_size)*max_threads = 466718 K bytes of memory Hope that's ok; if not, decrease some variables in the equation. Thread pointer: 0x561c5f5a26b0 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 = 0x7f5abc06bd80 thread_stack 0x48000 /usr/libexec/mysqld(my_print_stacktrace+0x3d)[0x561c5cb4acbd] /usr/libexec/mysqld(handle_fatal_signal+0x515)[0x561c5c75f4a5] sigaction.c:0(__restore_rt)[0x7f5ac12d85d0] :0(__GI_raise)[0x7f5abfa02207] :0(__GI_abort)[0x7f5abfa038f8] /usr/libexec/mysqld(+0x2d73b7)[0x561c5c5923b7] /usr/libexec/mysqld(+0x6f87d0)[0x561c5c9b37d0] /usr/libexec/mysqld(+0x657ade)[0x561c5c912ade] /usr/libexec/mysqld(+0x671153)[0x561c5c92c153] /usr/libexec/mysqld(+0x666faf)[0x561c5c921faf] /usr/libexec/mysqld(+0x668d94)[0x561c5c923d94] /usr/libexec/mysqld(+0x66a6c7)[0x561c5c9256c7] /usr/libexec/mysqld(+0x60a5a0)[0x561c5c8c55a0] /usr/libexec/mysqld(+0x60b54b)[0x561c5c8c654b] /usr/libexec/mysqld(_Z19ha_commit_one_phaseP3THDb+0x80)[0x561c5c761ac0] /usr/libexec/mysqld(_Z15ha_commit_transP3THDb+0x356)[0x561c5c762236] /usr/libexec/mysqld(_Z17trans_commit_stmtP3THD+0x1b)[0x561c5c6f53bb] /usr/libexec/mysqld(_Z21mysql_execute_commandP3THD+0x3dc)[0x561c5c62d9ec] /usr/libexec/mysqld(_Z11mysql_parseP3THDPcjP12Parser_state+0x125)[0x561c5c634445] /usr/libexec/mysqld(_Z16dispatch_command19enum_server_commandP3THDPcj+0x1750)[0x561c5c6364a0] /usr/libexec/mysqld(_Z24do_handle_one_connectionP3THD+0x1c2)[0x561c5c6e8a22] /usr/libexec/mysqld(handle_one_connection+0x4a)[0x561c5c6e8aca] pthread_create.c:0(start_thread)[0x7f5ac12d0dd5] /lib64/libc.so.6(clone+0x6d)[0x7f5abfac9ead] Trying to get some variables. Some pointers may be invalid and cause the dump to abort. Query (0x7f5a80004c18): UPDATE `ipaddresses` SET `lastSeen`='2019-04-23 13:55:10' WHERE `id`='5909' Connection ID (thread ID): 7 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=on,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=off,table_elimination=on,extended_keys=off 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. 190423 15:55:10 mysqld_safe Number of processes running now: 0 190423 15:55:10 mysqld_safe mysqld restarted 190423 15:55:10 [Note] /usr/libexec/mysqld (mysqld 5.5.60-MariaDB) starting as process 20744 ... 190423 15:55:10 InnoDB: The InnoDB memory heap is disabled 190423 15:55:10 InnoDB: Mutexes and rw_locks use GCC atomic builtins 190423 15:55:10 InnoDB: Compressed tables use zlib 1.2.7 190423 15:55:10 InnoDB: Using Linux native AIO 190423 15:55:11 InnoDB: Initializing buffer pool, size = 128.0M 190423 15:55:11 InnoDB: Completed initialization of buffer pool 190423 15:55:11 InnoDB: highest supported file format is Barracuda. 190423 15:55:11 InnoDB: Starting crash recovery from checkpoint LSN=16479099 InnoDB: Restoring possible half-written data pages from the doublewrite buffer... 190423 15:55:11 InnoDB: Starting final batch to recover 6 pages from redo log 190423 15:55:11 InnoDB: Waiting for the background threads to start 190423 15:55:12 Percona XtraDB (http://www.percona.com) 5.5.59-MariaDB-38.11 started; log sequence number 16493125 190423 15:55:12 [Note] Plugin 'FEEDBACK' is disabled. 190423 15:55:12 [Note] Server socket created on IP: '0.0.0.0'. 190423 15:55:12 [Note] Event Scheduler: Loaded 0 events 190423 15:55:12 [Note] /usr/libexec/mysqld: ready for connections. Version: '5.5.60-MariaDB' socket: '/data/mysql/mysql.sock' port: 3306 MariaDB Server 190423 15:57:17 InnoDB: Assertion failure in thread 140091836364544 in file fut0lst.ic line 83 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: http://dev.mysql.com/doc/refman/5.5/en/forcing-innodb-recovery.html InnoDB: about forcing recovery. 190423 15:57:17 [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 http://kb.askmonty.org/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: 5.5.60-MariaDB key_buffer_size=134217728 read_buffer_size=131072 max_used_connections=2 max_threads=153 thread_count=1 It is possible that mysqld could use up to key_buffer_size + (read_buffer_size + sort_buffer_size)*max_threads = 466718 K bytes of memory Hope that's ok; if not, decrease some variables in the equation. Thread pointer: 0x55e1068bf5f0 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 = 0x7f69ac246d80 thread_stack 0x48000 /usr/libexec/mysqld(my_print_stacktrace+0x3d)[0x55e102f9ccbd] /usr/libexec/mysqld(handle_fatal_signal+0x515)[0x55e102bb14a5] sigaction.c:0(__restore_rt)[0x7f69b2e955d0] :0(__GI_raise)[0x7f69b15bf207] :0(__GI_abort)[0x7f69b15c08f8] /usr/libexec/mysqld(+0x2d73b7)[0x55e1029e43b7] /usr/libexec/mysqld(+0x6f87d0)[0x55e102e057d0] /usr/libexec/mysqld(+0x657ade)[0x55e102d64ade] /usr/libexec/mysqld(+0x671153)[0x55e102d7e153] /usr/libexec/mysqld(+0x666faf)[0x55e102d73faf] /usr/libexec/mysqld(+0x668d94)[0x55e102d75d94] /usr/libexec/mysqld(+0x66a6c7)[0x55e102d776c7] /usr/libexec/mysqld(+0x60a5a0)[0x55e102d175a0] /usr/libexec/mysqld(+0x60b54b)[0x55e102d1854b] /usr/libexec/mysqld(_Z19ha_commit_one_phaseP3THDb+0x80)[0x55e102bb3ac0] /usr/libexec/mysqld(_Z15ha_commit_transP3THDb+0x356)[0x55e102bb4236] /usr/libexec/mysqld(_Z17trans_commit_stmtP3THD+0x1b)[0x55e102b473bb] /usr/libexec/mysqld(_Z21mysql_execute_commandP3THD+0x3dc)[0x55e102a7f9ec] /usr/libexec/mysqld(_Z11mysql_parseP3THDPcjP12Parser_state+0x125)[0x55e102a86445] /usr/libexec/mysqld(_Z16dispatch_command19enum_server_commandP3THDPcj+0x1750)[0x55e102a884a0] /usr/libexec/mysqld(_Z24do_handle_one_connectionP3THD+0x1c2)[0x55e102b3aa22] /usr/libexec/mysqld(handle_one_connection+0x4a)[0x55e102b3aaca] pthread_create.c:0(start_thread)[0x7f69b2e8ddd5] /lib64/libc.so.6(clone+0x6d)[0x7f69b1686ead] Trying to get some variables. Some pointers may be invalid and cause the dump to abort. Query (0x7f6968004c18): UPDATE `ipaddresses` SET `lastSeen`='2019-04-23 13:57:12' WHERE `id`='5906' Connection ID (thread ID): 6 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=on,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=off,table_elimination=on,extended_keys=off 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. 190423 15:57:17 mysqld_safe Number of processes running now: 0 190423 15:57:17 mysqld_safe mysqld restarted 190423 15:57:18 [Note] /usr/libexec/mysqld (mysqld 5.5.60-MariaDB) starting as process 21510 ... 190423 15:57:18 InnoDB: The InnoDB memory heap is disabled 190423 15:57:18 InnoDB: Mutexes and rw_locks use GCC atomic builtins 190423 15:57:18 InnoDB: Compressed tables use zlib 1.2.7 190423 15:57:18 InnoDB: Using Linux native AIO 190423 15:57:18 InnoDB: Initializing buffer pool, size = 128.0M 190423 15:57:18 InnoDB: Completed initialization of buffer pool 190423 15:57:18 InnoDB: highest supported file format is Barracuda. 190423 15:57:18 InnoDB: Starting crash recovery from checkpoint LSN=16493416 InnoDB: Restoring possible half-written data pages from the doublewrite buffer... 190423 15:57:18 InnoDB: Starting final batch to recover 5 pages from redo log 190423 15:57:18 InnoDB: Waiting for the background threads to start 190423 15:57:19 Percona XtraDB (http://www.percona.com) 5.5.59-MariaDB-38.11 started; log sequence number 16505416 190423 15:57:19 [Note] Plugin 'FEEDBACK' is disabled. 190423 15:57:19 [Note] Server socket created on IP: '0.0.0.0'. 190423 15:57:19 [Note] Event Scheduler: Loaded 0 events 190423 15:57:19 [Note] /usr/libexec/mysqld: ready for connections. Version: '5.5.60-MariaDB' socket: '/data/mysql/mysql.sock' port: 3306 MariaDB Server 190423 15:59:06 InnoDB: Assertion failure in thread 139650395350784 in file fut0lst.ic line 83 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: http://dev.mysql.com/doc/refman/5.5/en/forcing-innodb-recovery.html InnoDB: about forcing recovery. 190423 15:59:06 [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 http://kb.askmonty.org/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: 5.5.60-MariaDB key_buffer_size=134217728 read_buffer_size=131072 max_used_connections=2 max_threads=153 thread_count=1 It is possible that mysqld could use up to key_buffer_size + (read_buffer_size + sort_buffer_size)*max_threads = 466718 K bytes of memory Hope that's ok; if not, decrease some variables in the equation. Thread pointer: 0x55b2f60469d0 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 = 0x7f02e4351d80 thread_stack 0x48000 /usr/libexec/mysqld(my_print_stacktrace+0x3d)[0x55b2f37b2cbd] /usr/libexec/mysqld(handle_fatal_signal+0x515)[0x55b2f33c74a5] sigaction.c:0(__restore_rt)[0x7f02e82585d0] :0(__GI_raise)[0x7f02e6982207] :0(__GI_abort)[0x7f02e69838f8] /usr/libexec/mysqld(+0x2d73b7)[0x55b2f31fa3b7] /usr/libexec/mysqld(+0x6f87d0)[0x55b2f361b7d0] /usr/libexec/mysqld(+0x657ade)[0x55b2f357aade] /usr/libexec/mysqld(+0x671153)[0x55b2f3594153] /usr/libexec/mysqld(+0x666faf)[0x55b2f3589faf] /usr/libexec/mysqld(+0x668d94)[0x55b2f358bd94] /usr/libexec/mysqld(+0x66a6c7)[0x55b2f358d6c7] /usr/libexec/mysqld(+0x60a5a0)[0x55b2f352d5a0] /usr/libexec/mysqld(+0x60b54b)[0x55b2f352e54b] /usr/libexec/mysqld(_Z19ha_commit_one_phaseP3THDb+0x80)[0x55b2f33c9ac0] /usr/libexec/mysqld(_Z15ha_commit_transP3THDb+0x356)[0x55b2f33ca236] /usr/libexec/mysqld(_Z17trans_commit_stmtP3THD+0x1b)[0x55b2f335d3bb] /usr/libexec/mysqld(_Z21mysql_execute_commandP3THD+0x3dc)[0x55b2f32959ec] /usr/libexec/mysqld(_Z11mysql_parseP3THDPcjP12Parser_state+0x125)[0x55b2f329c445] /usr/libexec/mysqld(_Z16dispatch_command19enum_server_commandP3THDPcj+0x1750)[0x55b2f329e4a0] /usr/libexec/mysqld(_Z24do_handle_one_connectionP3THD+0x1c2)[0x55b2f3350a22] /usr/libexec/mysqld(handle_one_connection+0x4a)[0x55b2f3350aca] pthread_create.c:0(start_thread)[0x7f02e8250dd5] /lib64/libc.so.6(clone+0x6d)[0x7f02e6a49ead] Trying to get some variables. Some pointers may be invalid and cause the dump to abort. Query (0x7f02a4004c18): UPDATE `ipaddresses` SET `lastSeen`='2019-04-23 15:59:00' WHERE `id`='5909' Connection ID (thread ID): 24 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=on,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=off,table_elimination=on,extended_keys=off 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. 190423 15:59:06 mysqld_safe Number of processes running now: 0 190423 15:59:06 mysqld_safe mysqld restarted 190423 15:59:06 [Note] /usr/libexec/mysqld (mysqld 5.5.60-MariaDB) starting as process 22216 ... 190423 15:59:06 InnoDB: The InnoDB memory heap is disabled 190423 15:59:06 InnoDB: Mutexes and rw_locks use GCC atomic builtins 190423 15:59:06 InnoDB: Compressed tables use zlib 1.2.7 190423 15:59:06 InnoDB: Using Linux native AIO 190423 15:59:06 InnoDB: Initializing buffer pool, size = 128.0M 190423 15:59:06 InnoDB: Completed initialization of buffer pool 190423 15:59:06 InnoDB: highest supported file format is Barracuda. 190423 15:59:06 InnoDB: Starting crash recovery from checkpoint LSN=16508887 InnoDB: Restoring possible half-written data pages from the doublewrite buffer... 190423 15:59:06 InnoDB: Starting final batch to recover 5 pages from redo log 190423 15:59:06 InnoDB: Waiting for the background threads to start 190423 15:59:07 Percona XtraDB (http://www.percona.com) 5.5.59-MariaDB-38.11 started; log sequence number 16521279 190423 15:59:08 [Note] Plugin 'FEEDBACK' is disabled. 190423 15:59:08 [Note] Server socket created on IP: '0.0.0.0'. 190423 15:59:08 [Note] Event Scheduler: Loaded 0 events 190423 15:59:08 [Note] /usr/libexec/mysqld: ready for connections. Version: '5.5.60-MariaDB' socket: '/data/mysql/mysql.sock' port: 3306 MariaDB Server 190423 16:08:08 mysqld_safe Number of processes running now: 0 190423 16:08:08 mysqld_safe mysqld restarted 190423 16:08:08 [Note] /usr/libexec/mysqld (mysqld 5.5.60-MariaDB) starting as process 23099 ... 190423 16:08:08 InnoDB: The InnoDB memory heap is disabled 190423 16:08:08 InnoDB: Mutexes and rw_locks use GCC atomic builtins 190423 16:08:08 InnoDB: Compressed tables use zlib 1.2.7 190423 16:08:08 InnoDB: Using Linux native AIO 190423 16:08:08 InnoDB: Initializing buffer pool, size = 128.0M 190423 16:08:08 InnoDB: Completed initialization of buffer pool 190423 16:08:08 InnoDB: highest supported file format is Barracuda. 190423 16:08:08 InnoDB: Starting crash recovery from checkpoint LSN=16527314 InnoDB: Restoring possible half-written data pages from the doublewrite buffer... 190423 16:08:08 InnoDB: Starting final batch to recover 3 pages from redo log 190423 16:08:08 InnoDB: Waiting for the background threads to start 190423 16:08:09 Percona XtraDB (http://www.percona.com) 5.5.59-MariaDB-38.11 started; log sequence number 16536979 190423 16:08:09 [Note] Plugin 'FEEDBACK' is disabled. 190423 16:08:09 [Note] Server socket created on IP: '0.0.0.0'. 190423 16:08:09 [Note] Event Scheduler: Loaded 0 events 190423 16:08:09 [Note] /usr/libexec/mysqld: ready for connections. Version: '5.5.60-MariaDB' socket: '/data/mysql/mysql.sock' port: 3306 MariaDB Server 190423 17:03:57 InnoDB: Assertion failure in thread 140257686791936 in file fut0lst.ic line 83 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: http://dev.mysql.com/doc/refman/5.5/en/forcing-innodb-recovery.html InnoDB: about forcing recovery. 190423 17:03:57 [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 http://kb.askmonty.org/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: 5.5.60-MariaDB key_buffer_size=134217728 read_buffer_size=131072 max_used_connections=3 max_threads=153 thread_count=1 It is possible that mysqld could use up to key_buffer_size + (read_buffer_size + sort_buffer_size)*max_threads = 466718 K bytes of memory Hope that's ok; if not, decrease some variables in the equation. Thread pointer: 0x55982df351d0 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 = 0x7f9049991d80 thread_stack 0x48000 /usr/libexec/mysqld(my_print_stacktrace+0x3d)[0x55982adf2cbd] /usr/libexec/mysqld(handle_fatal_signal+0x515)[0x55982aa074a5] sigaction.c:0(__restore_rt)[0x7f9066c795d0] :0(__GI_raise)[0x7f90653a3207] :0(__GI_abort)[0x7f90653a48f8] /usr/libexec/mysqld(+0x2d73b7)[0x55982a83a3b7] /usr/libexec/mysqld(+0x6f87d0)[0x55982ac5b7d0] /usr/libexec/mysqld(+0x657ade)[0x55982abbaade] /usr/libexec/mysqld(+0x671153)[0x55982abd4153] /usr/libexec/mysqld(+0x666faf)[0x55982abc9faf] /usr/libexec/mysqld(+0x668d94)[0x55982abcbd94] /usr/libexec/mysqld(+0x66a6c7)[0x55982abcd6c7] /usr/libexec/mysqld(+0x60a5a0)[0x55982ab6d5a0] /usr/libexec/mysqld(+0x60b54b)[0x55982ab6e54b] /usr/libexec/mysqld(_Z19ha_commit_one_phaseP3THDb+0x80)[0x55982aa09ac0] /usr/libexec/mysqld(_Z15ha_commit_transP3THDb+0x356)[0x55982aa0a236] /usr/libexec/mysqld(_Z17trans_commit_stmtP3THD+0x1b)[0x55982a99d3bb] /usr/libexec/mysqld(_Z21mysql_execute_commandP3THD+0x3dc)[0x55982a8d59ec] /usr/libexec/mysqld(_Z11mysql_parseP3THDPcjP12Parser_state+0x125)[0x55982a8dc445] /usr/libexec/mysqld(_Z16dispatch_command19enum_server_commandP3THDPcj+0x1750)[0x55982a8de4a0] /usr/libexec/mysqld(_Z24do_handle_one_connectionP3THD+0x1c2)[0x55982a990a22] /usr/libexec/mysqld(handle_one_connection+0x4a)[0x55982a990aca] pthread_create.c:0(start_thread)[0x7f9066c71dd5] /lib64/libc.so.6(clone+0x6d)[0x7f906546aead] Trying to get some variables. Some pointers may be invalid and cause the dump to abort. Query (0x7f90240c3628): UPDATE `users` SET `lastLogin`='2019-04-23 15:03:57' WHERE `id`='6' Connection ID (thread ID): 92 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=on,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=off,table_elimination=on,extended_keys=off 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. 190423 17:03:57 mysqld_safe Number of processes running now: 0 190423 17:03:57 mysqld_safe mysqld restarted 190423 17:03:57 [Note] /usr/libexec/mysqld (mysqld 5.5.60-MariaDB) starting as process 24421 ... 190423 17:03:57 InnoDB: The InnoDB memory heap is disabled 190423 17:03:57 InnoDB: Mutexes and rw_locks use GCC atomic builtins 190423 17:03:57 InnoDB: Compressed tables use zlib 1.2.7 190423 17:03:57 InnoDB: Using Linux native AIO 190423 17:03:57 InnoDB: Initializing buffer pool, size = 128.0M 190423 17:03:57 InnoDB: Completed initialization of buffer pool 190423 17:03:57 InnoDB: highest supported file format is Barracuda. 190423 17:03:57 InnoDB: Starting crash recovery from checkpoint LSN=16560248 InnoDB: Restoring possible half-written data pages from the doublewrite buffer... 190423 17:03:57 InnoDB: Starting final batch to recover 1 pages from redo log 190423 17:03:58 InnoDB: Waiting for the background threads to start 190423 17:03:59 Percona XtraDB (http://www.percona.com) 5.5.59-MariaDB-38.11 started; log sequence number 16560445 190423 17:03:59 [Note] Plugin 'FEEDBACK' is disabled. 190423 17:03:59 [Note] Server socket created on IP: '0.0.0.0'. 190423 17:03:59 [Note] Event Scheduler: Loaded 0 events 190423 17:03:59 [Note] /usr/libexec/mysqld: ready for connections. Version: '5.5.60-MariaDB' socket: '/data/mysql/mysql.sock' port: 3306 MariaDB Server 190423 17:15:14 InnoDB: Assertion failure in thread 140526166775552 in file fut0lst.ic line 83 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: http://dev.mysql.com/doc/refman/5.5/en/forcing-innodb-recovery.html InnoDB: about forcing recovery. 190423 17:15:14 [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 http://kb.askmonty.org/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: 5.5.60-MariaDB key_buffer_size=134217728 read_buffer_size=131072 max_used_connections=7 max_threads=153 thread_count=1 It is possible that mysqld could use up to key_buffer_size + (read_buffer_size + sort_buffer_size)*max_threads = 466718 K bytes of memory Hope that's ok; if not, decrease some variables in the equation. Thread pointer: 0x55b1b0489e50 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 = 0x7fcecc408d80 thread_stack 0x48000 /usr/libexec/mysqld(my_print_stacktrace+0x3d)[0x55b1ae4a1cbd] /usr/libexec/mysqld(handle_fatal_signal+0x515)[0x55b1ae0b64a5] sigaction.c:0(__restore_rt)[0x7fced0ba45d0] :0(__GI_raise)[0x7fcecf2ce207] :0(__GI_abort)[0x7fcecf2cf8f8] /usr/libexec/mysqld(+0x2d73b7)[0x55b1adee93b7] /usr/libexec/mysqld(+0x6f87d0)[0x55b1ae30a7d0] /usr/libexec/mysqld(+0x657ade)[0x55b1ae269ade] /usr/libexec/mysqld(+0x671153)[0x55b1ae283153] /usr/libexec/mysqld(+0x666faf)[0x55b1ae278faf] /usr/libexec/mysqld(+0x668d94)[0x55b1ae27ad94] /usr/libexec/mysqld(+0x66a6c7)[0x55b1ae27c6c7] /usr/libexec/mysqld(+0x60a5a0)[0x55b1ae21c5a0] /usr/libexec/mysqld(+0x60b54b)[0x55b1ae21d54b] /usr/libexec/mysqld(_Z19ha_commit_one_phaseP3THDb+0x80)[0x55b1ae0b8ac0] /usr/libexec/mysqld(_Z15ha_commit_transP3THDb+0x356)[0x55b1ae0b9236] /usr/libexec/mysqld(_Z17trans_commit_stmtP3THD+0x1b)[0x55b1ae04c3bb] /usr/libexec/mysqld(_Z21mysql_execute_commandP3THD+0x3dc)[0x55b1adf849ec] /usr/libexec/mysqld(_Z11mysql_parseP3THDPcjP12Parser_state+0x125)[0x55b1adf8b445] /usr/libexec/mysqld(_Z16dispatch_command19enum_server_commandP3THDPcj+0x1750)[0x55b1adf8d4a0] /usr/libexec/mysqld(_Z24do_handle_one_connectionP3THD+0x1c2)[0x55b1ae03fa22] /usr/libexec/mysqld(handle_one_connection+0x4a)[0x55b1ae03faca] pthread_create.c:0(start_thread)[0x7fced0b9cdd5] /lib64/libc.so.6(clone+0x6d)[0x7fcecf395ead] Trying to get some variables. Some pointers may be invalid and cause the dump to abort. Query (0x7fce8c004c18): UPDATE `ipaddresses` SET `lastSeen`='2019-04-23 17:15:02' WHERE `id`='6140' Connection ID (thread ID): 587 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=on,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=off,table_elimination=on,extended_keys=off 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. 190423 17:15:14 mysqld_safe Number of processes running now: 0 190423 17:15:14 mysqld_safe mysqld restarted 190423 17:15:14 [Note] /usr/libexec/mysqld (mysqld 5.5.60-MariaDB) starting as process 26915 ... 190423 17:15:14 InnoDB: The InnoDB memory heap is disabled 190423 17:15:14 InnoDB: Mutexes and rw_locks use GCC atomic builtins 190423 17:15:14 InnoDB: Compressed tables use zlib 1.2.7 190423 17:15:14 InnoDB: Using Linux native AIO 190423 17:15:14 InnoDB: Initializing buffer pool, size = 128.0M 190423 17:15:14 InnoDB: Completed initialization of buffer pool 190423 17:15:14 InnoDB: highest supported file format is Barracuda. 190423 17:15:14 InnoDB: Starting crash recovery from checkpoint LSN=16670940 InnoDB: Restoring possible half-written data pages from the doublewrite buffer... 190423 17:15:14 InnoDB: Starting final batch to recover 2 pages from redo log 190423 17:15:14 InnoDB: Waiting for the background threads to start 190423 17:15:15 Percona XtraDB (http://www.percona.com) 5.5.59-MariaDB-38.11 started; log sequence number 16697102 190423 17:15:15 [Note] Plugin 'FEEDBACK' is disabled. 190423 17:15:15 [Note] Server socket created on IP: '0.0.0.0'. 190423 17:15:16 [Note] Event Scheduler: Loaded 0 events 190423 17:15:16 [Note] /usr/libexec/mysqld: ready for connections. Version: '5.5.60-MariaDB' socket: '/data/mysql/mysql.sock' port: 3306 MariaDB Server 190423 17:16:45 InnoDB: Assertion failure in thread 140060496774912 in file fut0lst.ic line 83 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: http://dev.mysql.com/doc/refman/5.5/en/forcing-innodb-recovery.html InnoDB: about forcing recovery. 190423 17:16:45 [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 http://kb.askmonty.org/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: 5.5.60-MariaDB key_buffer_size=134217728 read_buffer_size=131072 max_used_connections=3 max_threads=153 thread_count=1 It is possible that mysqld could use up to key_buffer_size + (read_buffer_size + sort_buffer_size)*max_threads = 466718 K bytes of memory Hope that's ok; if not, decrease some variables in the equation. Thread pointer: 0x55b361b78140 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 = 0x7f6260283d80 thread_stack 0x48000 /usr/libexec/mysqld(my_print_stacktrace+0x3d)[0x55b35e6c4cbd] /usr/libexec/mysqld(handle_fatal_signal+0x515)[0x55b35e2d94a5] sigaction.c:0(__restore_rt)[0x7f6263f775d0] :0(__GI_raise)[0x7f62626a1207] :0(__GI_abort)[0x7f62626a28f8] /usr/libexec/mysqld(+0x2d73b7)[0x55b35e10c3b7] /usr/libexec/mysqld(+0x6f87d0)[0x55b35e52d7d0] /usr/libexec/mysqld(+0x657ade)[0x55b35e48cade] /usr/libexec/mysqld(+0x671153)[0x55b35e4a6153] /usr/libexec/mysqld(+0x666faf)[0x55b35e49bfaf] /usr/libexec/mysqld(+0x668d94)[0x55b35e49dd94] /usr/libexec/mysqld(+0x66a6c7)[0x55b35e49f6c7] /usr/libexec/mysqld(+0x60a5a0)[0x55b35e43f5a0] /usr/libexec/mysqld(+0x60b54b)[0x55b35e44054b] /usr/libexec/mysqld(_Z19ha_commit_one_phaseP3THDb+0x80)[0x55b35e2dbac0] /usr/libexec/mysqld(_Z15ha_commit_transP3THDb+0x356)[0x55b35e2dc236] /usr/libexec/mysqld(_Z17trans_commit_stmtP3THD+0x1b)[0x55b35e26f3bb] /usr/libexec/mysqld(_Z21mysql_execute_commandP3THD+0x3dc)[0x55b35e1a79ec] /usr/libexec/mysqld(_Z11mysql_parseP3THDPcjP12Parser_state+0x125)[0x55b35e1ae445] /usr/libexec/mysqld(_Z16dispatch_command19enum_server_commandP3THDPcj+0x1750)[0x55b35e1b04a0] /usr/libexec/mysqld(_Z24do_handle_one_connectionP3THD+0x1c2)[0x55b35e262a22] /usr/libexec/mysqld(handle_one_connection+0x4a)[0x55b35e262aca] pthread_create.c:0(start_thread)[0x7f6263f6fdd5] /lib64/libc.so.6(clone+0x6d)[0x7f6262768ead] Trying to get some variables. Some pointers may be invalid and cause the dump to abort. Query (0x7f6220004c18): UPDATE `users` SET `lastActivity`='2019-04-23 15:16:45' WHERE `id`='1' Connection ID (thread ID): 24 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=on,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=off,table_elimination=on,extended_keys=off 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. 190423 17:16:45 mysqld_safe Number of processes running now: 0 190423 17:16:45 mysqld_safe mysqld restarted 190423 17:16:45 [Note] /usr/libexec/mysqld (mysqld 5.5.60-MariaDB) starting as process 28565 ... 190423 17:16:45 InnoDB: The InnoDB memory heap is disabled 190423 17:16:45 InnoDB: Mutexes and rw_locks use GCC atomic builtins 190423 17:16:45 InnoDB: Compressed tables use zlib 1.2.7 190423 17:16:45 InnoDB: Using Linux native AIO 190423 17:16:45 InnoDB: Initializing buffer pool, size = 128.0M 190423 17:16:45 InnoDB: Completed initialization of buffer pool 190423 17:16:45 InnoDB: highest supported file format is Barracuda. InnoDB: The log sequence number in ibdata files does not match InnoDB: the log sequence number in the ib_logfiles! InnoDB: Restoring possible half-written data pages from the doublewrite buffer... 190423 17:16:45 InnoDB: Waiting for the background threads to start 190423 17:16:46 Percona XtraDB (http://www.percona.com) 5.5.59-MariaDB-38.11 started; log sequence number 16725184 190423 17:16:46 [Note] Plugin 'FEEDBACK' is disabled. 190423 17:16:46 [Note] Server socket created on IP: '0.0.0.0'. 190423 17:16:46 [Note] Event Scheduler: Loaded 0 events 190423 17:16:46 [Note] /usr/libexec/mysqld: ready for connections. Version: '5.5.60-MariaDB' socket: '/data/mysql/mysql.sock' port: 3306 MariaDB Server 190423 17:17:51 InnoDB: Assertion failure in thread 140390538209024 in file fut0lst.ic line 83 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: http://dev.mysql.com/doc/refman/5.5/en/forcing-innodb-recovery.html InnoDB: about forcing recovery. 190423 17:17:51 [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 http://kb.askmonty.org/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: 5.5.60-MariaDB key_buffer_size=134217728 read_buffer_size=131072 max_used_connections=2 max_threads=153 thread_count=1 It is possible that mysqld could use up to key_buffer_size + (read_buffer_size + sort_buffer_size)*max_threads = 466718 K bytes of memory Hope that's ok; if not, decrease some variables in the equation. Thread pointer: 0x55cfc1c58040 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 = 0x7faf3828dd80 thread_stack 0x48000 /usr/libexec/mysqld(my_print_stacktrace+0x3d)[0x55cfbe7d3cbd] /usr/libexec/mysqld(handle_fatal_signal+0x515)[0x55cfbe3e84a5] sigaction.c:0(__restore_rt)[0x7faf3f0ef5d0] :0(__GI_raise)[0x7faf3d819207] :0(__GI_abort)[0x7faf3d81a8f8] /usr/libexec/mysqld(+0x2d73b7)[0x55cfbe21b3b7] /usr/libexec/mysqld(+0x6f87d0)[0x55cfbe63c7d0] /usr/libexec/mysqld(+0x657ade)[0x55cfbe59bade] /usr/libexec/mysqld(+0x671153)[0x55cfbe5b5153] /usr/libexec/mysqld(+0x666faf)[0x55cfbe5aafaf] /usr/libexec/mysqld(+0x668d94)[0x55cfbe5acd94] /usr/libexec/mysqld(+0x66a6c7)[0x55cfbe5ae6c7] /usr/libexec/mysqld(+0x60a5a0)[0x55cfbe54e5a0] /usr/libexec/mysqld(+0x60b54b)[0x55cfbe54f54b] /usr/libexec/mysqld(_Z19ha_commit_one_phaseP3THDb+0x80)[0x55cfbe3eaac0] /usr/libexec/mysqld(_Z15ha_commit_transP3THDb+0x356)[0x55cfbe3eb236] /usr/libexec/mysqld(_Z17trans_commit_stmtP3THD+0x1b)[0x55cfbe37e3bb] /usr/libexec/mysqld(_Z21mysql_execute_commandP3THD+0x3dc)[0x55cfbe2b69ec] /usr/libexec/mysqld(_Z11mysql_parseP3THDPcjP12Parser_state+0x125)[0x55cfbe2bd445] /usr/libexec/mysqld(_Z16dispatch_command19enum_server_commandP3THDPcj+0x1750)[0x55cfbe2bf4a0] /usr/libexec/mysqld(_Z24do_handle_one_connectionP3THD+0x1c2)[0x55cfbe371a22] /usr/libexec/mysqld(handle_one_connection+0x4a)[0x55cfbe371aca] pthread_create.c:0(start_thread)[0x7faf3f0e7dd5] /lib64/libc.so.6(clone+0x6d)[0x7faf3d8e0ead] Trying to get some variables. Some pointers may be invalid and cause the dump to abort. Query (0x7faf08004c18): UPDATE `users` SET `lastActivity`='2019-04-23 15:17:51' WHERE `id`='1' Connection ID (thread ID): 32 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=on,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=off,table_elimination=on,extended_keys=off 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. 190423 17:17:51 mysqld_safe Number of processes running now: 0 190423 17:17:51 mysqld_safe mysqld restarted 190423 17:17:51 [Note] /usr/libexec/mysqld (mysqld 5.5.60-MariaDB) starting as process 28697 ... 190423 17:17:51 InnoDB: The InnoDB memory heap is disabled 190423 17:17:51 InnoDB: Mutexes and rw_locks use GCC atomic builtins 190423 17:17:51 InnoDB: Compressed tables use zlib 1.2.7 190423 17:17:51 InnoDB: Using Linux native AIO 190423 17:17:51 InnoDB: Initializing buffer pool, size = 128.0M 190423 17:17:51 InnoDB: Completed initialization of buffer pool 190423 17:17:51 InnoDB: highest supported file format is Barracuda. InnoDB: The log sequence number in ibdata files does not match InnoDB: the log sequence number in the ib_logfiles! InnoDB: Restoring possible half-written data pages from the doublewrite buffer... 190423 17:17:51 InnoDB: Waiting for the background threads to start 190423 17:17:52 Percona XtraDB (http://www.percona.com) 5.5.59-MariaDB-38.11 started; log sequence number 16728039 190423 17:17:52 [Note] Plugin 'FEEDBACK' is disabled. 190423 17:17:52 [Note] Server socket created on IP: '0.0.0.0'. 190423 17:17:52 [Note] Event Scheduler: Loaded 0 events 190423 17:17:52 [Note] /usr/libexec/mysqld: ready for connections. Version: '5.5.60-MariaDB' socket: '/data/mysql/mysql.sock' port: 3306 MariaDB Server 190423 17:28:47 InnoDB: Assertion failure in thread 139709982537472 in file fut0lst.ic line 83 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: http://dev.mysql.com/doc/refman/5.5/en/forcing-innodb-recovery.html InnoDB: about forcing recovery. 190423 17:28:47 [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 http://kb.askmonty.org/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: 5.5.60-MariaDB key_buffer_size=134217728 read_buffer_size=131072 max_used_connections=7 max_threads=153 thread_count=1 It is possible that mysqld could use up to key_buffer_size + (read_buffer_size + sort_buffer_size)*max_threads = 466718 K bytes of memory Hope that's ok; if not, decrease some variables in the equation. Thread pointer: 0x555d0b0e8140 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 = 0x7f10c3e16d80 thread_stack 0x48000 /usr/libexec/mysqld(my_print_stacktrace+0x3d)[0x555d07983cbd] /usr/libexec/mysqld(handle_fatal_signal+0x515)[0x555d075984a5] sigaction.c:0(__restore_rt)[0x7f10e10e55d0] :0(__GI_raise)[0x7f10df80f207] :0(__GI_abort)[0x7f10df8108f8] /usr/libexec/mysqld(+0x2d73b7)[0x555d073cb3b7] /usr/libexec/mysqld(+0x6f87d0)[0x555d077ec7d0] /usr/libexec/mysqld(+0x657ade)[0x555d0774bade] /usr/libexec/mysqld(+0x671153)[0x555d07765153] /usr/libexec/mysqld(+0x666faf)[0x555d0775afaf] /usr/libexec/mysqld(+0x668d94)[0x555d0775cd94] /usr/libexec/mysqld(+0x66a6c7)[0x555d0775e6c7] /usr/libexec/mysqld(+0x60a5a0)[0x555d076fe5a0] /usr/libexec/mysqld(+0x60b54b)[0x555d076ff54b] /usr/libexec/mysqld(_Z19ha_commit_one_phaseP3THDb+0x80)[0x555d0759aac0] /usr/libexec/mysqld(_Z15ha_commit_transP3THDb+0x356)[0x555d0759b236] /usr/libexec/mysqld(_Z17trans_commit_stmtP3THD+0x1b)[0x555d0752e3bb] /usr/libexec/mysqld(_Z21mysql_execute_commandP3THD+0x3dc)[0x555d074669ec] /usr/libexec/mysqld(_Z11mysql_parseP3THDPcjP12Parser_state+0x125)[0x555d0746d445] /usr/libexec/mysqld(_Z16dispatch_command19enum_server_commandP3THDPcj+0x1750)[0x555d0746f4a0] /usr/libexec/mysqld(_Z24do_handle_one_connectionP3THD+0x1c2)[0x555d07521a22] /usr/libexec/mysqld(handle_one_connection+0x4a)[0x555d07521aca] pthread_create.c:0(start_thread)[0x7f10e10dddd5] /lib64/libc.so.6(clone+0x6d)[0x7f10df8d6ead] Trying to get some variables. Some pointers may be invalid and cause the dump to abort. Query (0x7f10940048e8): UPDATE `subnets` SET `isFolder`='0',`masterSubnetId`='0',`subnet`='183465472',`mask`='24',`description`='Database Management VLAN ID:640',`vlanId`='95',`allowRequests`='0',`showName`='0',`discoverSubnet`='0',`pingSubnet`='0',`resolveDNS`='0',`scanAgent`='0',`DNSrecursive`='0',`DNSrecords`='0',`nameserverId`='0',`device`='0',`isFull`='0',`location`='0',`threshold`='0',`sectionId`='9',`custom_Gateway`='10.239.118.1',`custom_Routing_information`=NULL WHERE `id`='342' Connection ID (thread ID): 375 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=on,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=off,table_elimination=on,extended_keys=off 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. 190423 17:28:47 mysqld_safe Number of processes running now: 0 190423 17:28:47 mysqld_safe mysqld restarted 190423 17:28:47 [Note] /usr/libexec/mysqld (mysqld 5.5.60-MariaDB) starting as process 2484 ... 190423 17:28:47 InnoDB: The InnoDB memory heap is disabled 190423 17:28:47 InnoDB: Mutexes and rw_locks use GCC atomic builtins 190423 17:28:47 InnoDB: Compressed tables use zlib 1.2.7 190423 17:28:47 InnoDB: Using Linux native AIO 190423 17:28:47 InnoDB: Initializing buffer pool, size = 128.0M 190423 17:28:47 InnoDB: Completed initialization of buffer pool 190423 17:28:47 InnoDB: highest supported file format is Barracuda. 190423 17:28:47 InnoDB: Starting crash recovery from checkpoint LSN=16855189 InnoDB: Restoring possible half-written data pages from the doublewrite buffer... 190423 17:28:47 InnoDB: Starting final batch to recover 1 pages from redo log 190423 17:28:48 InnoDB: Waiting for the background threads to start 190423 17:28:49 Percona XtraDB (http://www.percona.com) 5.5.59-MariaDB-38.11 started; log sequence number 16855463 190423 17:28:49 [Note] Plugin 'FEEDBACK' is disabled. 190423 17:28:49 [Note] Server socket created on IP: '0.0.0.0'. 190423 17:28:49 [Note] Event Scheduler: Loaded 0 events 190423 17:28:49 [Note] /usr/libexec/mysqld: ready for connections. Version: '5.5.60-MariaDB' socket: '/data/mysql/mysql.sock' port: 3306 MariaDB Server 190423 17:30:13 InnoDB: Assertion failure in thread 140000168138496 in file fut0lst.ic line 83 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: http://dev.mysql.com/doc/refman/5.5/en/forcing-innodb-recovery.html InnoDB: about forcing recovery. 190423 17:30:13 [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 http://kb.askmonty.org/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: 5.5.60-MariaDB key_buffer_size=134217728 read_buffer_size=131072 max_used_connections=3 max_threads=153 thread_count=1 It is possible that mysqld could use up to key_buffer_size + (read_buffer_size + sort_buffer_size)*max_threads = 466718 K bytes of memory Hope that's ok; if not, decrease some variables in the equation. Thread pointer: 0x55feb0c09040 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 = 0x7f54544a4d80 thread_stack 0x48000 /usr/libexec/mysqld(my_print_stacktrace+0x3d)[0x55feae8edcbd] /usr/libexec/mysqld(handle_fatal_signal+0x515)[0x55feae5024a5] sigaction.c:0(__restore_rt)[0x7f545ab4f5d0] :0(__GI_raise)[0x7f5459279207] :0(__GI_abort)[0x7f545927a8f8] /usr/libexec/mysqld(+0x2d73b7)[0x55feae3353b7] /usr/libexec/mysqld(+0x6f87d0)[0x55feae7567d0] /usr/libexec/mysqld(+0x657ade)[0x55feae6b5ade] /usr/libexec/mysqld(+0x671153)[0x55feae6cf153] /usr/libexec/mysqld(+0x666faf)[0x55feae6c4faf] /usr/libexec/mysqld(+0x668d94)[0x55feae6c6d94] /usr/libexec/mysqld(+0x66a6c7)[0x55feae6c86c7] /usr/libexec/mysqld(+0x60a5a0)[0x55feae6685a0] /usr/libexec/mysqld(+0x60b54b)[0x55feae66954b] /usr/libexec/mysqld(_Z19ha_commit_one_phaseP3THDb+0x80)[0x55feae504ac0] /usr/libexec/mysqld(_Z15ha_commit_transP3THDb+0x356)[0x55feae505236] /usr/libexec/mysqld(_Z17trans_commit_stmtP3THD+0x1b)[0x55feae4983bb] /usr/libexec/mysqld(_Z21mysql_execute_commandP3THD+0x3dc)[0x55feae3d09ec] /usr/libexec/mysqld(_Z11mysql_parseP3THDPcjP12Parser_state+0x125)[0x55feae3d7445] /usr/libexec/mysqld(_Z16dispatch_command19enum_server_commandP3THDPcj+0x1750)[0x55feae3d94a0] /usr/libexec/mysqld(_Z24do_handle_one_connectionP3THD+0x1c2)[0x55feae48ba22] /usr/libexec/mysqld(handle_one_connection+0x4a)[0x55feae48baca] pthread_create.c:0(start_thread)[0x7f545ab47dd5] /lib64/libc.so.6(clone+0x6d)[0x7f5459340ead] Trying to get some variables. Some pointers may be invalid and cause the dump to abort. Query (0x7f541005aeb8): UPDATE `ipaddresses` SET `lastSeen`='2019-04-23 17:30:02' WHERE `id`='5968' Connection ID (thread ID): 44 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=on,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=off,table_elimination=on,extended_keys=off 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. 190423 17:30:13 mysqld_safe Number of processes running now: 0 190423 17:30:13 mysqld_safe mysqld restarted 190423 17:30:14 [Note] /usr/libexec/mysqld (mysqld 5.5.60-MariaDB) starting as process 3908 ... 190423 17:30:14 InnoDB: The InnoDB memory heap is disabled 190423 17:30:14 InnoDB: Mutexes and rw_locks use GCC atomic builtins 190423 17:30:14 InnoDB: Compressed tables use zlib 1.2.7 190423 17:30:14 InnoDB: Using Linux native AIO 190423 17:30:14 InnoDB: Initializing buffer pool, size = 128.0M 190423 17:30:14 InnoDB: Completed initialization of buffer pool 190423 17:30:14 InnoDB: highest supported file format is Barracuda. 190423 17:30:14 InnoDB: Starting crash recovery from checkpoint LSN=16863488 InnoDB: Restoring possible half-written data pages from the doublewrite buffer... 190423 17:30:14 InnoDB: Starting final batch to recover 2 pages from redo log 190423 17:30:14 InnoDB: Waiting for the background threads to start 190423 17:30:15 Percona XtraDB (http://www.percona.com) 5.5.59-MariaDB-38.11 started; log sequence number 16865386 190423 17:30:15 [Note] Plugin 'FEEDBACK' is disabled. 190423 17:30:15 [Note] Server socket created on IP: '0.0.0.0'. 190423 17:30:15 [Note] Event Scheduler: Loaded 0 events 190423 17:30:15 [Note] /usr/libexec/mysqld: ready for connections. Version: '5.5.60-MariaDB' socket: '/data/mysql/mysql.sock' port: 3306 MariaDB Server 190423 17:37:02 InnoDB: Assertion failure in thread 140182540801792 in file fut0lst.ic line 83 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: http://dev.mysql.com/doc/refman/5.5/en/forcing-innodb-recovery.html InnoDB: about forcing recovery. 190423 17:37:02 [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 http://kb.askmonty.org/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: 5.5.60-MariaDB key_buffer_size=134217728 read_buffer_size=131072 max_used_connections=6 max_threads=153 thread_count=1 It is possible that mysqld could use up to key_buffer_size + (read_buffer_size + sort_buffer_size)*max_threads = 466718 K bytes of memory Hope that's ok; if not, decrease some variables in the equation. Thread pointer: 0x55f3f7608090 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 = 0x7f7eca8c4d80 thread_stack 0x48000 /usr/libexec/mysqld(my_print_stacktrace+0x3d)[0x55f3f41dccbd] /usr/libexec/mysqld(handle_fatal_signal+0x515)[0x55f3f3df14a5] sigaction.c:0(__restore_rt)[0x7f7ee7cde5d0] :0(__GI_raise)[0x7f7ee6408207] :0(__GI_abort)[0x7f7ee64098f8] /usr/libexec/mysqld(+0x2d73b7)[0x55f3f3c243b7] /usr/libexec/mysqld(+0x6f87d0)[0x55f3f40457d0] /usr/libexec/mysqld(+0x657ade)[0x55f3f3fa4ade] /usr/libexec/mysqld(+0x671153)[0x55f3f3fbe153] /usr/libexec/mysqld(+0x666faf)[0x55f3f3fb3faf] /usr/libexec/mysqld(+0x668d94)[0x55f3f3fb5d94] /usr/libexec/mysqld(+0x66a6c7)[0x55f3f3fb76c7] /usr/libexec/mysqld(+0x60a5a0)[0x55f3f3f575a0] /usr/libexec/mysqld(+0x60b54b)[0x55f3f3f5854b] /usr/libexec/mysqld(_Z19ha_commit_one_phaseP3THDb+0x80)[0x55f3f3df3ac0] /usr/libexec/mysqld(_Z15ha_commit_transP3THDb+0x356)[0x55f3f3df4236] /usr/libexec/mysqld(_Z17trans_commit_stmtP3THD+0x1b)[0x55f3f3d873bb] /usr/libexec/mysqld(_Z21mysql_execute_commandP3THD+0x3dc)[0x55f3f3cbf9ec] /usr/libexec/mysqld(_Z11mysql_parseP3THDPcjP12Parser_state+0x125)[0x55f3f3cc6445] /usr/libexec/mysqld(_Z16dispatch_command19enum_server_commandP3THDPcj+0x1750)[0x55f3f3cc84a0] /usr/libexec/mysqld(_Z24do_handle_one_connectionP3THD+0x1c2)[0x55f3f3d7aa22] /usr/libexec/mysqld(handle_one_connection+0x4a)[0x55f3f3d7aaca] pthread_create.c:0(start_thread)[0x7f7ee7cd6dd5] /lib64/libc.so.6(clone+0x6d)[0x7f7ee64cfead] Trying to get some variables. Some pointers may be invalid and cause the dump to abort. Query (0x7f7ea0004c18): UPDATE `users` SET `lastActivity`='2019-04-23 15:37:02' WHERE `id`='1' Connection ID (thread ID): 238 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=on,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=off,table_elimination=on,extended_keys=off 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. 190423 17:37:02 mysqld_safe Number of processes running now: 0 190423 17:37:02 mysqld_safe mysqld restarted 190423 17:37:03 [Note] /usr/libexec/mysqld (mysqld 5.5.60-MariaDB) starting as process 5557 ... 190423 17:37:03 InnoDB: The InnoDB memory heap is disabled 190423 17:37:03 InnoDB: Mutexes and rw_locks use GCC atomic builtins 190423 17:37:03 InnoDB: Compressed tables use zlib 1.2.7 190423 17:37:03 InnoDB: Using Linux native AIO 190423 17:37:03 InnoDB: Initializing buffer pool, size = 128.0M 190423 17:37:03 InnoDB: Completed initialization of buffer pool 190423 17:37:03 InnoDB: highest supported file format is Barracuda. 190423 17:37:03 InnoDB: Starting crash recovery from checkpoint LSN=16903486 InnoDB: Restoring possible half-written data pages from the doublewrite buffer... 190423 17:37:03 InnoDB: Starting final batch to recover 3 pages from redo log 190423 17:37:03 InnoDB: Waiting for the background threads to start 190423 17:37:04 Percona XtraDB (http://www.percona.com) 5.5.59-MariaDB-38.11 started; log sequence number 16904265 190423 17:37:04 [Note] Plugin 'FEEDBACK' is disabled. 190423 17:37:04 [Note] Server socket created on IP: '0.0.0.0'. 190423 17:37:04 [Note] Event Scheduler: Loaded 0 events 190423 17:37:04 [Note] /usr/libexec/mysqld: ready for connections. Version: '5.5.60-MariaDB' socket: '/data/mysql/mysql.sock' port: 3306 MariaDB Server 190423 17:45:13 InnoDB: Assertion failure in thread 140193777211136 in file fut0lst.ic line 83 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: http://dev.mysql.com/doc/refman/5.5/en/forcing-innodb-recovery.html InnoDB: about forcing recovery. 190423 17:45:13 [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 http://kb.askmonty.org/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: 5.5.60-MariaDB key_buffer_size=134217728 read_buffer_size=131072 max_used_connections=4 max_threads=153 thread_count=1 It is possible that mysqld could use up to key_buffer_size + (read_buffer_size + sort_buffer_size)*max_threads = 466718 K bytes of memory Hope that's ok; if not, decrease some variables in the equation. Thread pointer: 0x562fe1cc5e20 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 = 0x7f81684a4d80 thread_stack 0x48000 /usr/libexec/mysqld(my_print_stacktrace+0x3d)[0x562fde8d2cbd] /usr/libexec/mysqld(handle_fatal_signal+0x515)[0x562fde4e74a5] sigaction.c:0(__restore_rt)[0x7f816db4d5d0] :0(__GI_raise)[0x7f816c277207] :0(__GI_abort)[0x7f816c2788f8] /usr/libexec/mysqld(+0x2d73b7)[0x562fde31a3b7] /usr/libexec/mysqld(+0x6f87d0)[0x562fde73b7d0] /usr/libexec/mysqld(+0x657ade)[0x562fde69aade] /usr/libexec/mysqld(+0x671153)[0x562fde6b4153] /usr/libexec/mysqld(+0x666faf)[0x562fde6a9faf] /usr/libexec/mysqld(+0x668d94)[0x562fde6abd94] /usr/libexec/mysqld(+0x66a6c7)[0x562fde6ad6c7] /usr/libexec/mysqld(+0x60a5a0)[0x562fde64d5a0] /usr/libexec/mysqld(+0x60b54b)[0x562fde64e54b] /usr/libexec/mysqld(_Z19ha_commit_one_phaseP3THDb+0x80)[0x562fde4e9ac0] /usr/libexec/mysqld(_Z15ha_commit_transP3THDb+0x356)[0x562fde4ea236] /usr/libexec/mysqld(_Z17trans_commit_stmtP3THD+0x1b)[0x562fde47d3bb] /usr/libexec/mysqld(_Z21mysql_execute_commandP3THD+0x3dc)[0x562fde3b59ec] /usr/libexec/mysqld(_Z11mysql_parseP3THDPcjP12Parser_state+0x125)[0x562fde3bc445] /usr/libexec/mysqld(_Z16dispatch_command19enum_server_commandP3THDPcj+0x1750)[0x562fde3be4a0] /usr/libexec/mysqld(_Z24do_handle_one_connectionP3THD+0x1c2)[0x562fde470a22] /usr/libexec/mysqld(handle_one_connection+0x4a)[0x562fde470aca] pthread_create.c:0(start_thread)[0x7f816db45dd5] /lib64/libc.so.6(clone+0x6d)[0x7f816c33eead] Trying to get some variables. Some pointers may be invalid and cause the dump to abort. Query (0x7f8124004c18): UPDATE `ipaddresses` SET `lastSeen`='2019-04-23 17:45:02' WHERE `id`='5936' Connection ID (thread ID): 108 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=on,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=off,table_elimination=on,extended_keys=off 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. 190423 17:45:14 mysqld_safe Number of processes running now: 0 190423 17:45:14 mysqld_safe mysqld restarted 190423 17:45:14 [Note] /usr/libexec/mysqld (mysqld 5.5.60-MariaDB) starting as process 8424 ... 190423 17:45:14 InnoDB: The InnoDB memory heap is disabled 190423 17:45:14 InnoDB: Mutexes and rw_locks use GCC atomic builtins 190423 17:45:14 InnoDB: Compressed tables use zlib 1.2.7 190423 17:45:14 InnoDB: Using Linux native AIO 190423 17:45:14 InnoDB: Initializing buffer pool, size = 128.0M 190423 17:45:14 InnoDB: Completed initialization of buffer pool 190423 17:45:14 InnoDB: highest supported file format is Barracuda. 190423 17:45:14 InnoDB: Starting crash recovery from checkpoint LSN=16922994 InnoDB: Restoring possible half-written data pages from the doublewrite buffer... 190423 17:45:14 InnoDB: Starting final batch to recover 2 pages from redo log 190423 17:45:14 InnoDB: Waiting for the background threads to start 190423 17:45:15 Percona XtraDB (http://www.percona.com) 5.5.59-MariaDB-38.11 started; log sequence number 16950481 190423 17:45:15 [Note] Plugin 'FEEDBACK' is disabled. 190423 17:45:15 [Note] Server socket created on IP: '0.0.0.0'. 190423 17:45:15 [Note] Event Scheduler: Loaded 0 events 190423 17:45:15 [Note] /usr/libexec/mysqld: ready for connections. Version: '5.5.60-MariaDB' socket: '/data/mysql/mysql.sock' port: 3306 MariaDB Server 190423 18:00:13 InnoDB: Assertion failure in thread 140414948402944 in file fut0lst.ic line 83 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: http://dev.mysql.com/doc/refman/5.5/en/forcing-innodb-recovery.html InnoDB: about forcing recovery. 190423 18:00:13 [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 http://kb.askmonty.org/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: 5.5.60-MariaDB key_buffer_size=134217728 read_buffer_size=131072 max_used_connections=3 max_threads=153 thread_count=1 It is possible that mysqld could use up to key_buffer_size + (read_buffer_size + sort_buffer_size)*max_threads = 466718 K bytes of memory Hope that's ok; if not, decrease some variables in the equation. Thread pointer: 0x56320e8201b0 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 = 0x7fb4e71edd80 thread_stack 0x48000 /usr/libexec/mysqld(my_print_stacktrace+0x3d)[0x56320b1f1cbd] /usr/libexec/mysqld(handle_fatal_signal+0x515)[0x56320ae064a5] sigaction.c:0(__restore_rt)[0x7fb5044d45d0] :0(__GI_raise)[0x7fb502bfe207] :0(__GI_abort)[0x7fb502bff8f8] /usr/libexec/mysqld(+0x2d73b7)[0x56320ac393b7] /usr/libexec/mysqld(+0x6f87d0)[0x56320b05a7d0] /usr/libexec/mysqld(+0x657ade)[0x56320afb9ade] /usr/libexec/mysqld(+0x671153)[0x56320afd3153] /usr/libexec/mysqld(+0x666faf)[0x56320afc8faf] /usr/libexec/mysqld(+0x668d94)[0x56320afcad94] /usr/libexec/mysqld(+0x66a6c7)[0x56320afcc6c7] /usr/libexec/mysqld(+0x60a5a0)[0x56320af6c5a0] /usr/libexec/mysqld(+0x60b54b)[0x56320af6d54b] /usr/libexec/mysqld(_Z19ha_commit_one_phaseP3THDb+0x80)[0x56320ae08ac0] /usr/libexec/mysqld(_Z15ha_commit_transP3THDb+0x356)[0x56320ae09236] /usr/libexec/mysqld(_Z17trans_commit_stmtP3THD+0x1b)[0x56320ad9c3bb] /usr/libexec/mysqld(_Z21mysql_execute_commandP3THD+0x3dc)[0x56320acd49ec] /usr/libexec/mysqld(_Z11mysql_parseP3THDPcjP12Parser_state+0x125)[0x56320acdb445] /usr/libexec/mysqld(_Z16dispatch_command19enum_server_commandP3THDPcj+0x1750)[0x56320acdd4a0] /usr/libexec/mysqld(_Z24do_handle_one_connectionP3THD+0x1c2)[0x56320ad8fa22] /usr/libexec/mysqld(handle_one_connection+0x4a)[0x56320ad8faca] pthread_create.c:0(start_thread)[0x7fb5044ccdd5] /lib64/libc.so.6(clone+0x6d)[0x7fb502cc5ead] Trying to get some variables. Some pointers may be invalid and cause the dump to abort. Query (0x7fb4bc004c18): UPDATE `ipaddresses` SET `lastSeen`='2019-04-23 18:00:02' WHERE `id`='5956' Connection ID (thread ID): 12 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=on,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=off,table_elimination=on,extended_keys=off 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. 190423 18:00:14 mysqld_safe Number of processes running now: 0 190423 18:00:14 mysqld_safe mysqld restarted 190423 18:00:14 [Note] /usr/libexec/mysqld (mysqld 5.5.60-MariaDB) starting as process 10317 ... 190423 18:00:14 InnoDB: The InnoDB memory heap is disabled 190423 18:00:14 InnoDB: Mutexes and rw_locks use GCC atomic builtins 190423 18:00:14 InnoDB: Compressed tables use zlib 1.2.7 190423 18:00:14 InnoDB: Using Linux native AIO 190423 18:00:14 InnoDB: Initializing buffer pool, size = 128.0M 190423 18:00:14 InnoDB: Completed initialization of buffer pool 190423 18:00:14 InnoDB: highest supported file format is Barracuda. 190423 18:00:14 InnoDB: Starting crash recovery from checkpoint LSN=16956360 InnoDB: Restoring possible half-written data pages from the doublewrite buffer... 190423 18:00:14 InnoDB: Starting final batch to recover 2 pages from redo log 190423 18:00:14 InnoDB: Waiting for the background threads to start 190423 18:00:15 Percona XtraDB (http://www.percona.com) 5.5.59-MariaDB-38.11 started; log sequence number 16988692 190423 18:00:15 [Note] Plugin 'FEEDBACK' is disabled. 190423 18:00:15 [Note] Server socket created on IP: '0.0.0.0'. 190423 18:00:15 [Note] Event Scheduler: Loaded 0 events 190423 18:00:15 [Note] /usr/libexec/mysqld: ready for connections. Version: '5.5.60-MariaDB' socket: '/data/mysql/mysql.sock' port: 3306 MariaDB Server 190423 18:15:14 InnoDB: Assertion failure in thread 140279202457344 in file fut0lst.ic line 83 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: http://dev.mysql.com/doc/refman/5.5/en/forcing-innodb-recovery.html InnoDB: about forcing recovery. 190423 18:15:14 [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 http://kb.askmonty.org/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: 5.5.60-MariaDB key_buffer_size=134217728 read_buffer_size=131072 max_used_connections=3 max_threads=153 thread_count=1 It is possible that mysqld could use up to key_buffer_size + (read_buffer_size + sort_buffer_size)*max_threads = 466718 K bytes of memory Hope that's ok; if not, decrease some variables in the equation. Thread pointer: 0x55d51f745ab0 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 = 0x7f954c081d80 thread_stack 0x48000 /usr/libexec/mysqld(my_print_stacktrace+0x3d)[0x55d51dd4acbd] /usr/libexec/mysqld(handle_fatal_signal+0x515)[0x55d51d95f4a5] sigaction.c:0(__restore_rt)[0x7f95525575d0] :0(__GI_raise)[0x7f9550c81207] :0(__GI_abort)[0x7f9550c828f8] /usr/libexec/mysqld(+0x2d73b7)[0x55d51d7923b7] /usr/libexec/mysqld(+0x6f87d0)[0x55d51dbb37d0] /usr/libexec/mysqld(+0x657ade)[0x55d51db12ade] /usr/libexec/mysqld(+0x671153)[0x55d51db2c153] /usr/libexec/mysqld(+0x666faf)[0x55d51db21faf] /usr/libexec/mysqld(+0x668d94)[0x55d51db23d94] /usr/libexec/mysqld(+0x66a6c7)[0x55d51db256c7] /usr/libexec/mysqld(+0x60a5a0)[0x55d51dac55a0] /usr/libexec/mysqld(+0x60b54b)[0x55d51dac654b] /usr/libexec/mysqld(_Z19ha_commit_one_phaseP3THDb+0x80)[0x55d51d961ac0] /usr/libexec/mysqld(_Z15ha_commit_transP3THDb+0x356)[0x55d51d962236] /usr/libexec/mysqld(_Z17trans_commit_stmtP3THD+0x1b)[0x55d51d8f53bb] /usr/libexec/mysqld(_Z21mysql_execute_commandP3THD+0x3dc)[0x55d51d82d9ec] /usr/libexec/mysqld(_Z11mysql_parseP3THDPcjP12Parser_state+0x125)[0x55d51d834445] /usr/libexec/mysqld(_Z16dispatch_command19enum_server_commandP3THDPcj+0x1750)[0x55d51d8364a0] /usr/libexec/mysqld(_Z24do_handle_one_connectionP3THD+0x1c2)[0x55d51d8e8a22] /usr/libexec/mysqld(handle_one_connection+0x4a)[0x55d51d8e8aca] pthread_create.c:0(start_thread)[0x7f955254fdd5] /lib64/libc.so.6(clone+0x6d)[0x7f9550d48ead] Trying to get some variables. Some pointers may be invalid and cause the dump to abort. Query (0x7f950c004c18): UPDATE `ipaddresses` SET `lastSeen`='2019-04-23 18:15:01' WHERE `id`='5956' Connection ID (thread ID): 12 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=on,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=off,table_elimination=on,extended_keys=off 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. 190423 18:15:14 mysqld_safe Number of processes running now: 0 190423 18:15:14 mysqld_safe mysqld restarted 190423 18:15:14 [Note] /usr/libexec/mysqld (mysqld 5.5.60-MariaDB) starting as process 11754 ... 190423 18:15:14 InnoDB: The InnoDB memory heap is disabled 190423 18:15:14 InnoDB: Mutexes and rw_locks use GCC atomic builtins 190423 18:15:14 InnoDB: Compressed tables use zlib 1.2.7 190423 18:15:14 InnoDB: Using Linux native AIO 190423 18:15:14 InnoDB: Initializing buffer pool, size = 128.0M 190423 18:15:14 InnoDB: Completed initialization of buffer pool 190423 18:15:14 InnoDB: highest supported file format is Barracuda. 190423 18:15:14 InnoDB: Starting crash recovery from checkpoint LSN=16994570 InnoDB: Restoring possible half-written data pages from the doublewrite buffer... 190423 18:15:14 InnoDB: Starting final batch to recover 2 pages from redo log 190423 18:15:15 InnoDB: Waiting for the background threads to start 190423 18:15:16 Percona XtraDB (http://www.percona.com) 5.5.59-MariaDB-38.11 started; log sequence number 17025055 190423 18:15:16 [Note] Plugin 'FEEDBACK' is disabled. 190423 18:15:16 [Note] Server socket created on IP: '0.0.0.0'. 190423 18:15:16 [Note] Event Scheduler: Loaded 0 events 190423 18:15:16 [Note] /usr/libexec/mysqld: ready for connections. Version: '5.5.60-MariaDB' socket: '/data/mysql/mysql.sock' port: 3306 MariaDB Server 190423 18:30:14 InnoDB: Assertion failure in thread 140098261337856 in file fut0lst.ic line 83 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: http://dev.mysql.com/doc/refman/5.5/en/forcing-innodb-recovery.html InnoDB: about forcing recovery. 190423 18:30:14 [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 http://kb.askmonty.org/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: 5.5.60-MariaDB key_buffer_size=134217728 read_buffer_size=131072 max_used_connections=3 max_threads=153 thread_count=1 It is possible that mysqld could use up to key_buffer_size + (read_buffer_size + sort_buffer_size)*max_threads = 466718 K bytes of memory Hope that's ok; if not, decrease some variables in the equation. Thread pointer: 0x55c511991ab0 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 = 0x7f6b2b19bd80 thread_stack 0x48000 /usr/libexec/mysqld(my_print_stacktrace+0x3d)[0x55c50f7f5cbd] /usr/libexec/mysqld(handle_fatal_signal+0x515)[0x55c50f40a4a5] sigaction.c:0(__restore_rt)[0x7f6b4842d5d0] :0(__GI_raise)[0x7f6b46b57207] :0(__GI_abort)[0x7f6b46b588f8] /usr/libexec/mysqld(+0x2d73b7)[0x55c50f23d3b7] /usr/libexec/mysqld(+0x6f87d0)[0x55c50f65e7d0] /usr/libexec/mysqld(+0x657ade)[0x55c50f5bdade] /usr/libexec/mysqld(+0x671153)[0x55c50f5d7153] /usr/libexec/mysqld(+0x666faf)[0x55c50f5ccfaf] /usr/libexec/mysqld(+0x668d94)[0x55c50f5ced94] /usr/libexec/mysqld(+0x66a6c7)[0x55c50f5d06c7] /usr/libexec/mysqld(+0x60a5a0)[0x55c50f5705a0] /usr/libexec/mysqld(+0x60b54b)[0x55c50f57154b] /usr/libexec/mysqld(_Z19ha_commit_one_phaseP3THDb+0x80)[0x55c50f40cac0] /usr/libexec/mysqld(_Z15ha_commit_transP3THDb+0x356)[0x55c50f40d236] /usr/libexec/mysqld(_Z17trans_commit_stmtP3THD+0x1b)[0x55c50f3a03bb] /usr/libexec/mysqld(_Z21mysql_execute_commandP3THD+0x3dc)[0x55c50f2d89ec] /usr/libexec/mysqld(_Z11mysql_parseP3THDPcjP12Parser_state+0x125)[0x55c50f2df445] /usr/libexec/mysqld(_Z16dispatch_command19enum_server_commandP3THDPcj+0x1750)[0x55c50f2e14a0] /usr/libexec/mysqld(_Z24do_handle_one_connectionP3THD+0x1c2)[0x55c50f393a22] /usr/libexec/mysqld(handle_one_connection+0x4a)[0x55c50f393aca] pthread_create.c:0(start_thread)[0x7f6b48425dd5] /lib64/libc.so.6(clone+0x6d)[0x7f6b46c1eead] Trying to get some variables. Some pointers may be invalid and cause the dump to abort. Query (0x7f6b00004c18): UPDATE `ipaddresses` SET `lastSeen`='2019-04-23 18:30:01' WHERE `id`='5956' Connection ID (thread ID): 12 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=on,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=off,table_elimination=on,extended_keys=off 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. 190423 18:30:14 mysqld_safe Number of processes running now: 0 190423 18:30:14 mysqld_safe mysqld restarted 190423 18:30:14 [Note] /usr/libexec/mysqld (mysqld 5.5.60-MariaDB) starting as process 13651 ... 190423 18:30:14 InnoDB: The InnoDB memory heap is disabled 190423 18:30:14 InnoDB: Mutexes and rw_locks use GCC atomic builtins 190423 18:30:14 InnoDB: Compressed tables use zlib 1.2.7 190423 18:30:14 InnoDB: Using Linux native AIO 190423 18:30:14 InnoDB: Initializing buffer pool, size = 128.0M 190423 18:30:14 InnoDB: Completed initialization of buffer pool 190423 18:30:14 InnoDB: highest supported file format is Barracuda. 190423 18:30:14 InnoDB: Starting crash recovery from checkpoint LSN=17030933 InnoDB: Restoring possible half-written data pages from the doublewrite buffer... 190423 18:30:14 InnoDB: Starting final batch to recover 2 pages from redo log 190423 18:30:15 InnoDB: Waiting for the background threads to start 190423 18:30:16 Percona XtraDB (http://www.percona.com) 5.5.59-MariaDB-38.11 started; log sequence number 17061418 190423 18:30:16 [Note] Plugin 'FEEDBACK' is disabled. 190423 18:30:16 [Note] Server socket created on IP: '0.0.0.0'. 190423 18:30:16 [Note] Event Scheduler: Loaded 0 events 190423 18:30:16 [Note] /usr/libexec/mysqld: ready for connections. Version: '5.5.60-MariaDB' socket: '/data/mysql/mysql.sock' port: 3306 MariaDB Server 190423 18:45:13 InnoDB: Assertion failure in thread 139976210147072 in file fut0lst.ic line 83 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: http://dev.mysql.com/doc/refman/5.5/en/forcing-innodb-recovery.html InnoDB: about forcing recovery. 190423 18:45:13 [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 http://kb.askmonty.org/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: 5.5.60-MariaDB key_buffer_size=134217728 read_buffer_size=131072 max_used_connections=3 max_threads=153 thread_count=1 It is possible that mysqld could use up to key_buffer_size + (read_buffer_size + sort_buffer_size)*max_threads = 466718 K bytes of memory Hope that's ok; if not, decrease some variables in the equation. Thread pointer: 0x55d683b61ab0 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 = 0x7f4ec0485d80 thread_stack 0x48000 /usr/libexec/mysqld(my_print_stacktrace+0x3d)[0x55d6801d7cbd] /usr/libexec/mysqld(handle_fatal_signal+0x515)[0x55d67fdec4a5] sigaction.c:0(__restore_rt)[0x7f4ec4b8d5d0] :0(__GI_raise)[0x7f4ec32b7207] :0(__GI_abort)[0x7f4ec32b88f8] /usr/libexec/mysqld(+0x2d73b7)[0x55d67fc1f3b7] /usr/libexec/mysqld(+0x6f87d0)[0x55d6800407d0] /usr/libexec/mysqld(+0x657ade)[0x55d67ff9fade] /usr/libexec/mysqld(+0x671153)[0x55d67ffb9153] /usr/libexec/mysqld(+0x666faf)[0x55d67ffaefaf] /usr/libexec/mysqld(+0x668d94)[0x55d67ffb0d94] /usr/libexec/mysqld(+0x66a6c7)[0x55d67ffb26c7] /usr/libexec/mysqld(+0x60a5a0)[0x55d67ff525a0] /usr/libexec/mysqld(+0x60b54b)[0x55d67ff5354b] /usr/libexec/mysqld(_Z19ha_commit_one_phaseP3THDb+0x80)[0x55d67fdeeac0] /usr/libexec/mysqld(_Z15ha_commit_transP3THDb+0x356)[0x55d67fdef236] /usr/libexec/mysqld(_Z17trans_commit_stmtP3THD+0x1b)[0x55d67fd823bb] /usr/libexec/mysqld(_Z21mysql_execute_commandP3THD+0x3dc)[0x55d67fcba9ec] /usr/libexec/mysqld(_Z11mysql_parseP3THDPcjP12Parser_state+0x125)[0x55d67fcc1445] /usr/libexec/mysqld(_Z16dispatch_command19enum_server_commandP3THDPcj+0x1750)[0x55d67fcc34a0] /usr/libexec/mysqld(_Z24do_handle_one_connectionP3THD+0x1c2)[0x55d67fd75a22] /usr/libexec/mysqld(handle_one_connection+0x4a)[0x55d67fd75aca] pthread_create.c:0(start_thread)[0x7f4ec4b85dd5] /lib64/libc.so.6(clone+0x6d)[0x7f4ec337eead] Trying to get some variables. Some pointers may be invalid and cause the dump to abort. Query (0x7f4e7c004c18): UPDATE `ipaddresses` SET `lastSeen`='2019-04-23 18:45:01' WHERE `id`='5956' Connection ID (thread ID): 12 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=on,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=off,table_elimination=on,extended_keys=off 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. 190423 18:45:13 mysqld_safe Number of processes running now: 0 190423 18:45:13 mysqld_safe mysqld restarted 190423 18:45:13 [Note] /usr/libexec/mysqld (mysqld 5.5.60-MariaDB) starting as process 15079 ... 190423 18:45:13 InnoDB: The InnoDB memory heap is disabled 190423 18:45:13 InnoDB: Mutexes and rw_locks use GCC atomic builtins 190423 18:45:13 InnoDB: Compressed tables use zlib 1.2.7 190423 18:45:13 InnoDB: Using Linux native AIO 190423 18:45:13 InnoDB: Initializing buffer pool, size = 128.0M 190423 18:45:13 InnoDB: Completed initialization of buffer pool 190423 18:45:13 InnoDB: highest supported file format is Barracuda. 190423 18:45:13 InnoDB: Starting crash recovery from checkpoint LSN=17067296 InnoDB: Restoring possible half-written data pages from the doublewrite buffer... 190423 18:45:14 InnoDB: Starting final batch to recover 2 pages from redo log 190423 18:45:14 InnoDB: Waiting for the background threads to start 190423 18:45:15 Percona XtraDB (http://www.percona.com) 5.5.59-MariaDB-38.11 started; log sequence number 17097781 190423 18:45:15 [Note] Plugin 'FEEDBACK' is disabled. 190423 18:45:15 [Note] Server socket created on IP: '0.0.0.0'. 190423 18:45:15 [Note] Event Scheduler: Loaded 0 events 190423 18:45:15 [Note] /usr/libexec/mysqld: ready for connections. Version: '5.5.60-MariaDB' socket: '/data/mysql/mysql.sock' port: 3306 MariaDB Server 190423 19:00:13 InnoDB: Assertion failure in thread 140313364006656 in file fut0lst.ic line 83 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: http://dev.mysql.com/doc/refman/5.5/en/forcing-innodb-recovery.html InnoDB: about forcing recovery. 190423 19:00:13 [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 http://kb.askmonty.org/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: 5.5.60-MariaDB key_buffer_size=134217728 read_buffer_size=131072 max_used_connections=3 max_threads=153 thread_count=1 It is possible that mysqld could use up to key_buffer_size + (read_buffer_size + sort_buffer_size)*max_threads = 466718 K bytes of memory Hope that's ok; if not, decrease some variables in the equation. Thread pointer: 0x555a5629eab0 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 = 0x7f9d4037fd80 thread_stack 0x48000 /usr/libexec/mysqld(my_print_stacktrace+0x3d)[0x555a542facbd] /usr/libexec/mysqld(handle_fatal_signal+0x515)[0x555a53f0f4a5] sigaction.c:0(__restore_rt)[0x7f9d448745d0] :0(__GI_raise)[0x7f9d42f9e207] :0(__GI_abort)[0x7f9d42f9f8f8] /usr/libexec/mysqld(+0x2d73b7)[0x555a53d423b7] /usr/libexec/mysqld(+0x6f87d0)[0x555a541637d0] /usr/libexec/mysqld(+0x657ade)[0x555a540c2ade] /usr/libexec/mysqld(+0x671153)[0x555a540dc153] /usr/libexec/mysqld(+0x666faf)[0x555a540d1faf] /usr/libexec/mysqld(+0x668d94)[0x555a540d3d94] /usr/libexec/mysqld(+0x66a6c7)[0x555a540d56c7] /usr/libexec/mysqld(+0x60a5a0)[0x555a540755a0] /usr/libexec/mysqld(+0x60b54b)[0x555a5407654b] /usr/libexec/mysqld(_Z19ha_commit_one_phaseP3THDb+0x80)[0x555a53f11ac0] /usr/libexec/mysqld(_Z15ha_commit_transP3THDb+0x356)[0x555a53f12236] /usr/libexec/mysqld(_Z17trans_commit_stmtP3THD+0x1b)[0x555a53ea53bb] /usr/libexec/mysqld(_Z21mysql_execute_commandP3THD+0x3dc)[0x555a53ddd9ec] /usr/libexec/mysqld(_Z11mysql_parseP3THDPcjP12Parser_state+0x125)[0x555a53de4445] /usr/libexec/mysqld(_Z16dispatch_command19enum_server_commandP3THDPcj+0x1750)[0x555a53de64a0] /usr/libexec/mysqld(_Z24do_handle_one_connectionP3THD+0x1c2)[0x555a53e98a22] /usr/libexec/mysqld(handle_one_connection+0x4a)[0x555a53e98aca] pthread_create.c:0(start_thread)[0x7f9d4486cdd5] /lib64/libc.so.6(clone+0x6d)[0x7f9d43065ead] Trying to get some variables. Some pointers may be invalid and cause the dump to abort. Query (0x7f9cfc004c18): UPDATE `ipaddresses` SET `lastSeen`='2019-04-23 19:00:01' WHERE `id`='5956' Connection ID (thread ID): 12 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=on,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=off,table_elimination=on,extended_keys=off 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. 190423 19:00:14 mysqld_safe Number of processes running now: 0 190423 19:00:14 mysqld_safe mysqld restarted 190423 19:00:14 [Note] /usr/libexec/mysqld (mysqld 5.5.60-MariaDB) starting as process 16991 ... 190423 19:00:14 InnoDB: The InnoDB memory heap is disabled 190423 19:00:14 InnoDB: Mutexes and rw_locks use GCC atomic builtins 190423 19:00:14 InnoDB: Compressed tables use zlib 1.2.7 190423 19:00:14 InnoDB: Using Linux native AIO 190423 19:00:14 InnoDB: Initializing buffer pool, size = 128.0M 190423 19:00:14 InnoDB: Completed initialization of buffer pool 190423 19:00:14 InnoDB: highest supported file format is Barracuda. 190423 19:00:14 InnoDB: Starting crash recovery from checkpoint LSN=17103659 InnoDB: Restoring possible half-written data pages from the doublewrite buffer... 190423 19:00:14 InnoDB: Starting final batch to recover 2 pages from redo log 190423 19:00:14 InnoDB: Waiting for the background threads to start 190423 19:00:15 Percona XtraDB (http://www.percona.com) 5.5.59-MariaDB-38.11 started; log sequence number 17134144 190423 19:00:15 [Note] Plugin 'FEEDBACK' is disabled. 190423 19:00:15 [Note] Server socket created on IP: '0.0.0.0'. 190423 19:00:15 [Note] Event Scheduler: Loaded 0 events 190423 19:00:15 [Note] /usr/libexec/mysqld: ready for connections. Version: '5.5.60-MariaDB' socket: '/data/mysql/mysql.sock' port: 3306 MariaDB Server 190423 19:15:12 InnoDB: Assertion failure in thread 140030196438784 in file fut0lst.ic line 83 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: http://dev.mysql.com/doc/refman/5.5/en/forcing-innodb-recovery.html InnoDB: about forcing recovery. 190423 19:15:12 [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 http://kb.askmonty.org/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: 5.5.60-MariaDB key_buffer_size=134217728 read_buffer_size=131072 max_used_connections=3 max_threads=153 thread_count=1 It is possible that mysqld could use up to key_buffer_size + (read_buffer_size + sort_buffer_size)*max_threads = 466718 K bytes of memory Hope that's ok; if not, decrease some variables in the equation. Thread pointer: 0x562bfb5a9ab0 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 = 0x7f5b521dcd80 thread_stack 0x48000 /usr/libexec/mysqld(my_print_stacktrace+0x3d)[0x562bf8a0acbd] /usr/libexec/mysqld(handle_fatal_signal+0x515)[0x562bf861f4a5] sigaction.c:0(__restore_rt)[0x7f5b6f4dd5d0] :0(__GI_raise)[0x7f5b6dc07207] :0(__GI_abort)[0x7f5b6dc088f8] /usr/libexec/mysqld(+0x2d73b7)[0x562bf84523b7] /usr/libexec/mysqld(+0x6f87d0)[0x562bf88737d0] /usr/libexec/mysqld(+0x657ade)[0x562bf87d2ade] /usr/libexec/mysqld(+0x671153)[0x562bf87ec153] /usr/libexec/mysqld(+0x666faf)[0x562bf87e1faf] /usr/libexec/mysqld(+0x668d94)[0x562bf87e3d94] /usr/libexec/mysqld(+0x66a6c7)[0x562bf87e56c7] /usr/libexec/mysqld(+0x60a5a0)[0x562bf87855a0] /usr/libexec/mysqld(+0x60b54b)[0x562bf878654b] /usr/libexec/mysqld(_Z19ha_commit_one_phaseP3THDb+0x80)[0x562bf8621ac0] /usr/libexec/mysqld(_Z15ha_commit_transP3THDb+0x356)[0x562bf8622236] /usr/libexec/mysqld(_Z17trans_commit_stmtP3THD+0x1b)[0x562bf85b53bb] /usr/libexec/mysqld(_Z21mysql_execute_commandP3THD+0x3dc)[0x562bf84ed9ec] /usr/libexec/mysqld(_Z11mysql_parseP3THDPcjP12Parser_state+0x125)[0x562bf84f4445] /usr/libexec/mysqld(_Z16dispatch_command19enum_server_commandP3THDPcj+0x1750)[0x562bf84f64a0] /usr/libexec/mysqld(_Z24do_handle_one_connectionP3THD+0x1c2)[0x562bf85a8a22] /usr/libexec/mysqld(handle_one_connection+0x4a)[0x562bf85a8aca] pthread_create.c:0(start_thread)[0x7f5b6f4d5dd5] /lib64/libc.so.6(clone+0x6d)[0x7f5b6dcceead] Trying to get some variables. Some pointers may be invalid and cause the dump to abort. Query (0x7f5b28004c18): UPDATE `ipaddresses` SET `lastSeen`='2019-04-23 19:15:01' WHERE `id`='5956' Connection ID (thread ID): 12 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=on,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=off,table_elimination=on,extended_keys=off 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. 190423 19:15:12 mysqld_safe Number of processes running now: 0 190423 19:15:12 mysqld_safe mysqld restarted 190423 19:15:12 [Note] /usr/libexec/mysqld (mysqld 5.5.60-MariaDB) starting as process 18448 ... 190423 19:15:13 InnoDB: The InnoDB memory heap is disabled 190423 19:15:13 InnoDB: Mutexes and rw_locks use GCC atomic builtins 190423 19:15:13 InnoDB: Compressed tables use zlib 1.2.7 190423 19:15:13 InnoDB: Using Linux native AIO 190423 19:15:13 InnoDB: Initializing buffer pool, size = 128.0M 190423 19:15:13 InnoDB: Completed initialization of buffer pool 190423 19:15:13 InnoDB: highest supported file format is Barracuda. 190423 19:15:13 InnoDB: Starting crash recovery from checkpoint LSN=17140034 InnoDB: Restoring possible half-written data pages from the doublewrite buffer... 190423 19:15:13 InnoDB: Starting final batch to recover 2 pages from redo log 190423 19:15:13 InnoDB: Waiting for the background threads to start 190423 19:15:14 Percona XtraDB (http://www.percona.com) 5.5.59-MariaDB-38.11 started; log sequence number 17170519 190423 19:15:14 [Note] Plugin 'FEEDBACK' is disabled. 190423 19:15:14 [Note] Server socket created on IP: '0.0.0.0'. 190423 19:15:14 [Note] Event Scheduler: Loaded 0 events 190423 19:15:14 [Note] /usr/libexec/mysqld: ready for connections. Version: '5.5.60-MariaDB' socket: '/data/mysql/mysql.sock' port: 3306 MariaDB Server 190423 19:30:13 InnoDB: Assertion failure in thread 139624825169664 in file fut0lst.ic line 83 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: http://dev.mysql.com/doc/refman/5.5/en/forcing-innodb-recovery.html InnoDB: about forcing recovery. 190423 19:30:13 [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 http://kb.askmonty.org/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: 5.5.60-MariaDB key_buffer_size=134217728 read_buffer_size=131072 max_used_connections=3 max_threads=153 thread_count=1 It is possible that mysqld could use up to key_buffer_size + (read_buffer_size + sort_buffer_size)*max_threads = 466718 K bytes of memory Hope that's ok; if not, decrease some variables in the equation. Thread pointer: 0x55e32cafdab0 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 = 0x7efcf01b1d80 thread_stack 0x48000 /usr/libexec/mysqld(my_print_stacktrace+0x3d)[0x55e32a901cbd] /usr/libexec/mysqld(handle_fatal_signal+0x515)[0x55e32a5164a5] sigaction.c:0(__restore_rt)[0x7efcf4ea75d0] :0(__GI_raise)[0x7efcf35d1207] :0(__GI_abort)[0x7efcf35d28f8] /usr/libexec/mysqld(+0x2d73b7)[0x55e32a3493b7] /usr/libexec/mysqld(+0x6f87d0)[0x55e32a76a7d0] /usr/libexec/mysqld(+0x657ade)[0x55e32a6c9ade] /usr/libexec/mysqld(+0x671153)[0x55e32a6e3153] /usr/libexec/mysqld(+0x666faf)[0x55e32a6d8faf] /usr/libexec/mysqld(+0x668d94)[0x55e32a6dad94] /usr/libexec/mysqld(+0x66a6c7)[0x55e32a6dc6c7] /usr/libexec/mysqld(+0x60a5a0)[0x55e32a67c5a0] /usr/libexec/mysqld(+0x60b54b)[0x55e32a67d54b] /usr/libexec/mysqld(_Z19ha_commit_one_phaseP3THDb+0x80)[0x55e32a518ac0] /usr/libexec/mysqld(_Z15ha_commit_transP3THDb+0x356)[0x55e32a519236] /usr/libexec/mysqld(_Z17trans_commit_stmtP3THD+0x1b)[0x55e32a4ac3bb] /usr/libexec/mysqld(_Z21mysql_execute_commandP3THD+0x3dc)[0x55e32a3e49ec] /usr/libexec/mysqld(_Z11mysql_parseP3THDPcjP12Parser_state+0x125)[0x55e32a3eb445] /usr/libexec/mysqld(_Z16dispatch_command19enum_server_commandP3THDPcj+0x1750)[0x55e32a3ed4a0] /usr/libexec/mysqld(_Z24do_handle_one_connectionP3THD+0x1c2)[0x55e32a49fa22] /usr/libexec/mysqld(handle_one_connection+0x4a)[0x55e32a49faca] pthread_create.c:0(start_thread)[0x7efcf4e9fdd5] /lib64/libc.so.6(clone+0x6d)[0x7efcf3698ead] Trying to get some variables. Some pointers may be invalid and cause the dump to abort. Query (0x7efcb4004c18): UPDATE `ipaddresses` SET `lastSeen`='2019-04-23 19:30:02' WHERE `id`='5956' Connection ID (thread ID): 12 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=on,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=off,table_elimination=on,extended_keys=off 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. 190423 19:30:13 mysqld_safe Number of processes running now: 0 190423 19:30:13 mysqld_safe mysqld restarted 190423 19:30:14 [Note] /usr/libexec/mysqld (mysqld 5.5.60-MariaDB) starting as process 20352 ... 190423 19:30:14 InnoDB: The InnoDB memory heap is disabled 190423 19:30:14 InnoDB: Mutexes and rw_locks use GCC atomic builtins 190423 19:30:14 InnoDB: Compressed tables use zlib 1.2.7 190423 19:30:14 InnoDB: Using Linux native AIO 190423 19:30:14 InnoDB: Initializing buffer pool, size = 128.0M 190423 19:30:14 InnoDB: Completed initialization of buffer pool 190423 19:30:14 InnoDB: highest supported file format is Barracuda. 190423 19:30:14 InnoDB: Starting crash recovery from checkpoint LSN=17176633 InnoDB: Restoring possible half-written data pages from the doublewrite buffer... 190423 19:30:14 InnoDB: Starting final batch to recover 3 pages from redo log 190423 19:30:14 InnoDB: Waiting for the background threads to start 190423 19:30:15 Percona XtraDB (http://www.percona.com) 5.5.59-MariaDB-38.11 started; log sequence number 17207848 190423 19:30:15 [Note] Plugin 'FEEDBACK' is disabled. 190423 19:30:15 [Note] Server socket created on IP: '0.0.0.0'. 190423 19:30:15 [Note] Event Scheduler: Loaded 0 events 190423 19:30:15 [Note] /usr/libexec/mysqld: ready for connections. Version: '5.5.60-MariaDB' socket: '/data/mysql/mysql.sock' port: 3306 MariaDB Server 190423 19:45:15 InnoDB: Assertion failure in thread 139797035067136 in file fut0lst.ic line 83 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: http://dev.mysql.com/doc/refman/5.5/en/forcing-innodb-recovery.html InnoDB: about forcing recovery. 190423 19:45:15 [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 http://kb.askmonty.org/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: 5.5.60-MariaDB key_buffer_size=134217728 read_buffer_size=131072 max_used_connections=3 max_threads=153 thread_count=1 It is possible that mysqld could use up to key_buffer_size + (read_buffer_size + sort_buffer_size)*max_threads = 466718 K bytes of memory Hope that's ok; if not, decrease some variables in the equation. Thread pointer: 0x564eb3276ab0 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 = 0x7f25089d9d80 thread_stack 0x48000 /usr/libexec/mysqld(my_print_stacktrace+0x3d)[0x564eb11fccbd] /usr/libexec/mysqld(handle_fatal_signal+0x515)[0x564eb0e114a5] sigaction.c:0(__restore_rt)[0x7f2525ce75d0] :0(__GI_raise)[0x7f2524411207] :0(__GI_abort)[0x7f25244128f8] /usr/libexec/mysqld(+0x2d73b7)[0x564eb0c443b7] /usr/libexec/mysqld(+0x6f87d0)[0x564eb10657d0] /usr/libexec/mysqld(+0x657ade)[0x564eb0fc4ade] /usr/libexec/mysqld(+0x671153)[0x564eb0fde153] /usr/libexec/mysqld(+0x666faf)[0x564eb0fd3faf] /usr/libexec/mysqld(+0x668d94)[0x564eb0fd5d94] /usr/libexec/mysqld(+0x66a6c7)[0x564eb0fd76c7] /usr/libexec/mysqld(+0x60a5a0)[0x564eb0f775a0] /usr/libexec/mysqld(+0x60b54b)[0x564eb0f7854b] /usr/libexec/mysqld(_Z19ha_commit_one_phaseP3THDb+0x80)[0x564eb0e13ac0] /usr/libexec/mysqld(_Z15ha_commit_transP3THDb+0x356)[0x564eb0e14236] /usr/libexec/mysqld(_Z17trans_commit_stmtP3THD+0x1b)[0x564eb0da73bb] /usr/libexec/mysqld(_Z21mysql_execute_commandP3THD+0x3dc)[0x564eb0cdf9ec] /usr/libexec/mysqld(_Z11mysql_parseP3THDPcjP12Parser_state+0x125)[0x564eb0ce6445] /usr/libexec/mysqld(_Z16dispatch_command19enum_server_commandP3THDPcj+0x1750)[0x564eb0ce84a0] /usr/libexec/mysqld(_Z24do_handle_one_connectionP3THD+0x1c2)[0x564eb0d9aa22] /usr/libexec/mysqld(handle_one_connection+0x4a)[0x564eb0d9aaca] pthread_create.c:0(start_thread)[0x7f2525cdfdd5] /lib64/libc.so.6(clone+0x6d)[0x7f25244d8ead] Trying to get some variables. Some pointers may be invalid and cause the dump to abort. Query (0x7f24e0004c18): UPDATE `ipaddresses` SET `lastSeen`='2019-04-23 19:45:02' WHERE `id`='5956' Connection ID (thread ID): 12 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=on,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=off,table_elimination=on,extended_keys=off 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. 190423 19:45:15 mysqld_safe Number of processes running now: 0 190423 19:45:15 mysqld_safe mysqld restarted 190423 19:45:15 [Note] /usr/libexec/mysqld (mysqld 5.5.60-MariaDB) starting as process 21789 ... 190423 19:45:15 InnoDB: The InnoDB memory heap is disabled 190423 19:45:15 InnoDB: Mutexes and rw_locks use GCC atomic builtins 190423 19:45:15 InnoDB: Compressed tables use zlib 1.2.7 190423 19:45:15 InnoDB: Using Linux native AIO 190423 19:45:15 InnoDB: Initializing buffer pool, size = 128.0M 190423 19:45:15 InnoDB: Completed initialization of buffer pool 190423 19:45:15 InnoDB: highest supported file format is Barracuda. 190423 19:45:15 InnoDB: Starting crash recovery from checkpoint LSN=17213725 InnoDB: Restoring possible half-written data pages from the doublewrite buffer... 190423 19:45:15 InnoDB: Starting final batch to recover 2 pages from redo log 190423 19:45:15 InnoDB: Waiting for the background threads to start 190423 19:45:16 Percona XtraDB (http://www.percona.com) 5.5.59-MariaDB-38.11 started; log sequence number 17244210 190423 19:45:16 [Note] Plugin 'FEEDBACK' is disabled. 190423 19:45:16 [Note] Server socket created on IP: '0.0.0.0'. 190423 19:45:16 [Note] Event Scheduler: Loaded 0 events 190423 19:45:16 [Note] /usr/libexec/mysqld: ready for connections. Version: '5.5.60-MariaDB' socket: '/data/mysql/mysql.sock' port: 3306 MariaDB Server 190423 20:00:13 InnoDB: Assertion failure in thread 140021706868480 in file fut0lst.ic line 83 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: http://dev.mysql.com/doc/refman/5.5/en/forcing-innodb-recovery.html InnoDB: about forcing recovery. 190423 20:00:13 [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 http://kb.askmonty.org/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: 5.5.60-MariaDB key_buffer_size=134217728 read_buffer_size=131072 max_used_connections=3 max_threads=153 thread_count=1 It is possible that mysqld could use up to key_buffer_size + (read_buffer_size + sort_buffer_size)*max_threads = 466718 K bytes of memory Hope that's ok; if not, decrease some variables in the equation. Thread pointer: 0x55dd88113ab0 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 = 0x7f5958193d80 thread_stack 0x48000 /usr/libexec/mysqld(my_print_stacktrace+0x3d)[0x55dd8541ecbd] /usr/libexec/mysqld(handle_fatal_signal+0x515)[0x55dd850334a5] sigaction.c:0(__restore_rt)[0x7f595c09a5d0] :0(__GI_raise)[0x7f595a7c4207] :0(__GI_abort)[0x7f595a7c58f8] /usr/libexec/mysqld(+0x2d73b7)[0x55dd84e663b7] /usr/libexec/mysqld(+0x6f87d0)[0x55dd852877d0] /usr/libexec/mysqld(+0x657ade)[0x55dd851e6ade] /usr/libexec/mysqld(+0x671153)[0x55dd85200153] /usr/libexec/mysqld(+0x666faf)[0x55dd851f5faf] /usr/libexec/mysqld(+0x668d94)[0x55dd851f7d94] /usr/libexec/mysqld(+0x66a6c7)[0x55dd851f96c7] /usr/libexec/mysqld(+0x60a5a0)[0x55dd851995a0] /usr/libexec/mysqld(+0x60b54b)[0x55dd8519a54b] /usr/libexec/mysqld(_Z19ha_commit_one_phaseP3THDb+0x80)[0x55dd85035ac0] /usr/libexec/mysqld(_Z15ha_commit_transP3THDb+0x356)[0x55dd85036236] /usr/libexec/mysqld(_Z17trans_commit_stmtP3THD+0x1b)[0x55dd84fc93bb] /usr/libexec/mysqld(_Z21mysql_execute_commandP3THD+0x3dc)[0x55dd84f019ec] /usr/libexec/mysqld(_Z11mysql_parseP3THDPcjP12Parser_state+0x125)[0x55dd84f08445] /usr/libexec/mysqld(_Z16dispatch_command19enum_server_commandP3THDPcj+0x1750)[0x55dd84f0a4a0] /usr/libexec/mysqld(_Z24do_handle_one_connectionP3THD+0x1c2)[0x55dd84fbca22] /usr/libexec/mysqld(handle_one_connection+0x4a)[0x55dd84fbcaca] pthread_create.c:0(start_thread)[0x7f595c092dd5] /lib64/libc.so.6(clone+0x6d)[0x7f595a88bead] Trying to get some variables. Some pointers may be invalid and cause the dump to abort. Query (0x7f5914004c18): UPDATE `ipaddresses` SET `lastSeen`='2019-04-23 20:00:01' WHERE `id`='5956' Connection ID (thread ID): 12 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=on,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=off,table_elimination=on,extended_keys=off 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. 190423 20:00:13 mysqld_safe Number of processes running now: 0 190423 20:00:13 mysqld_safe mysqld restarted 190423 20:00:13 [Note] /usr/libexec/mysqld (mysqld 5.5.60-MariaDB) starting as process 23697 ... 190423 20:00:13 InnoDB: The InnoDB memory heap is disabled 190423 20:00:13 InnoDB: Mutexes and rw_locks use GCC atomic builtins 190423 20:00:13 InnoDB: Compressed tables use zlib 1.2.7 190423 20:00:13 InnoDB: Using Linux native AIO 190423 20:00:13 InnoDB: Initializing buffer pool, size = 128.0M 190423 20:00:13 InnoDB: Completed initialization of buffer pool 190423 20:00:13 InnoDB: highest supported file format is Barracuda. 190423 20:00:13 InnoDB: Starting crash recovery from checkpoint LSN=17250088 InnoDB: Restoring possible half-written data pages from the doublewrite buffer... 190423 20:00:13 InnoDB: Starting final batch to recover 2 pages from redo log 190423 20:00:13 InnoDB: Waiting for the background threads to start 190423 20:00:14 Percona XtraDB (http://www.percona.com) 5.5.59-MariaDB-38.11 started; log sequence number 17280573 190423 20:00:14 [Note] Plugin 'FEEDBACK' is disabled. 190423 20:00:14 [Note] Server socket created on IP: '0.0.0.0'. 190423 20:00:14 [Note] Event Scheduler: Loaded 0 events 190423 20:00:14 [Note] /usr/libexec/mysqld: ready for connections. Version: '5.5.60-MariaDB' socket: '/data/mysql/mysql.sock' port: 3306 MariaDB Server 190423 20:15:13 InnoDB: Assertion failure in thread 139758782408448 in file fut0lst.ic line 83 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: http://dev.mysql.com/doc/refman/5.5/en/forcing-innodb-recovery.html InnoDB: about forcing recovery. 190423 20:15:13 [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 http://kb.askmonty.org/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: 5.5.60-MariaDB key_buffer_size=134217728 read_buffer_size=131072 max_used_connections=3 max_threads=153 thread_count=1 It is possible that mysqld could use up to key_buffer_size + (read_buffer_size + sort_buffer_size)*max_threads = 466718 K bytes of memory Hope that's ok; if not, decrease some variables in the equation. Thread pointer: 0x55d771f39ab0 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 = 0x7f1c20945d80 thread_stack 0x48000 /usr/libexec/mysqld(my_print_stacktrace+0x3d)[0x55d76f4bdcbd] /usr/libexec/mysqld(handle_fatal_signal+0x515)[0x55d76f0d24a5] sigaction.c:0(__restore_rt)[0x7f1c3dbfe5d0] :0(__GI_raise)[0x7f1c3c328207] :0(__GI_abort)[0x7f1c3c3298f8] /usr/libexec/mysqld(+0x2d73b7)[0x55d76ef053b7] /usr/libexec/mysqld(+0x6f87d0)[0x55d76f3267d0] /usr/libexec/mysqld(+0x657ade)[0x55d76f285ade] /usr/libexec/mysqld(+0x671153)[0x55d76f29f153] /usr/libexec/mysqld(+0x666faf)[0x55d76f294faf] /usr/libexec/mysqld(+0x668d94)[0x55d76f296d94] /usr/libexec/mysqld(+0x66a6c7)[0x55d76f2986c7] /usr/libexec/mysqld(+0x60a5a0)[0x55d76f2385a0] /usr/libexec/mysqld(+0x60b54b)[0x55d76f23954b] /usr/libexec/mysqld(_Z19ha_commit_one_phaseP3THDb+0x80)[0x55d76f0d4ac0] /usr/libexec/mysqld(_Z15ha_commit_transP3THDb+0x356)[0x55d76f0d5236] /usr/libexec/mysqld(_Z17trans_commit_stmtP3THD+0x1b)[0x55d76f0683bb] /usr/libexec/mysqld(_Z21mysql_execute_commandP3THD+0x3dc)[0x55d76efa09ec] /usr/libexec/mysqld(_Z11mysql_parseP3THDPcjP12Parser_state+0x125)[0x55d76efa7445] /usr/libexec/mysqld(_Z16dispatch_command19enum_server_commandP3THDPcj+0x1750)[0x55d76efa94a0] /usr/libexec/mysqld(_Z24do_handle_one_connectionP3THD+0x1c2)[0x55d76f05ba22] /usr/libexec/mysqld(handle_one_connection+0x4a)[0x55d76f05baca] pthread_create.c:0(start_thread)[0x7f1c3dbf6dd5] /lib64/libc.so.6(clone+0x6d)[0x7f1c3c3efead] Trying to get some variables. Some pointers may be invalid and cause the dump to abort. Query (0x7f1bf8004c18): UPDATE `ipaddresses` SET `lastSeen`='2019-04-23 20:15:01' WHERE `id`='5956' Connection ID (thread ID): 12 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=on,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=off,table_elimination=on,extended_keys=off 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. 190423 20:15:13 mysqld_safe Number of processes running now: 0 190423 20:15:13 mysqld_safe mysqld restarted 190423 20:15:13 [Note] /usr/libexec/mysqld (mysqld 5.5.60-MariaDB) starting as process 25155 ... 190423 20:15:13 InnoDB: The InnoDB memory heap is disabled 190423 20:15:13 InnoDB: Mutexes and rw_locks use GCC atomic builtins 190423 20:15:13 InnoDB: Compressed tables use zlib 1.2.7 190423 20:15:13 InnoDB: Using Linux native AIO 190423 20:15:13 InnoDB: Initializing buffer pool, size = 128.0M 190423 20:15:13 InnoDB: Completed initialization of buffer pool 190423 20:15:13 InnoDB: highest supported file format is Barracuda. 190423 20:15:13 InnoDB: Starting crash recovery from checkpoint LSN=17286493 InnoDB: Restoring possible half-written data pages from the doublewrite buffer... 190423 20:15:13 InnoDB: Starting final batch to recover 2 pages from redo log 190423 20:15:14 InnoDB: Waiting for the background threads to start 190423 20:15:15 Percona XtraDB (http://www.percona.com) 5.5.59-MariaDB-38.11 started; log sequence number 17316994 190423 20:15:15 [Note] Plugin 'FEEDBACK' is disabled. 190423 20:15:15 [Note] Server socket created on IP: '0.0.0.0'. 190423 20:15:15 [Note] Event Scheduler: Loaded 0 events 190423 20:15:15 [Note] /usr/libexec/mysqld: ready for connections. Version: '5.5.60-MariaDB' socket: '/data/mysql/mysql.sock' port: 3306 MariaDB Server 190423 20:30:13 InnoDB: Assertion failure in thread 140626826360576 in file fut0lst.ic line 83 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: http://dev.mysql.com/doc/refman/5.5/en/forcing-innodb-recovery.html InnoDB: about forcing recovery. 190423 20:30:13 [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 http://kb.askmonty.org/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: 5.5.60-MariaDB key_buffer_size=134217728 read_buffer_size=131072 max_used_connections=3 max_threads=153 thread_count=1 It is possible that mysqld could use up to key_buffer_size + (read_buffer_size + sort_buffer_size)*max_threads = 466718 K bytes of memory Hope that's ok; if not, decrease some variables in the equation. Thread pointer: 0x5619c27988f0 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 = 0x7fe63c07ed80 thread_stack 0x48000 /usr/libexec/mysqld(my_print_stacktrace+0x3d)[0x5619c042acbd] /usr/libexec/mysqld(handle_fatal_signal+0x515)[0x5619c003f4a5] sigaction.c:0(__restore_rt)[0x7fe6405fb5d0] :0(__GI_raise)[0x7fe63ed25207] :0(__GI_abort)[0x7fe63ed268f8] /usr/libexec/mysqld(+0x2d73b7)[0x5619bfe723b7] /usr/libexec/mysqld(+0x6f87d0)[0x5619c02937d0] /usr/libexec/mysqld(+0x657ade)[0x5619c01f2ade] /usr/libexec/mysqld(+0x671153)[0x5619c020c153] /usr/libexec/mysqld(+0x666faf)[0x5619c0201faf] /usr/libexec/mysqld(+0x668d94)[0x5619c0203d94] /usr/libexec/mysqld(+0x66a6c7)[0x5619c02056c7] /usr/libexec/mysqld(+0x60a5a0)[0x5619c01a55a0] /usr/libexec/mysqld(+0x60b54b)[0x5619c01a654b] /usr/libexec/mysqld(_Z19ha_commit_one_phaseP3THDb+0x80)[0x5619c0041ac0] /usr/libexec/mysqld(_Z15ha_commit_transP3THDb+0x356)[0x5619c0042236] /usr/libexec/mysqld(_Z17trans_commit_stmtP3THD+0x1b)[0x5619bffd53bb] /usr/libexec/mysqld(_Z21mysql_execute_commandP3THD+0x3dc)[0x5619bff0d9ec] /usr/libexec/mysqld(_Z11mysql_parseP3THDPcjP12Parser_state+0x125)[0x5619bff14445] /usr/libexec/mysqld(_Z16dispatch_command19enum_server_commandP3THDPcj+0x1750)[0x5619bff164a0] /usr/libexec/mysqld(_Z24do_handle_one_connectionP3THD+0x1c2)[0x5619bffc8a22] /usr/libexec/mysqld(handle_one_connection+0x4a)[0x5619bffc8aca] pthread_create.c:0(start_thread)[0x7fe6405f3dd5] /lib64/libc.so.6(clone+0x6d)[0x7fe63edecead] Trying to get some variables. Some pointers may be invalid and cause the dump to abort. Query (0x7fe5f8004c18): UPDATE `ipaddresses` SET `lastSeen`='2019-04-23 20:30:01' WHERE `id`='5956' Connection ID (thread ID): 12 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=on,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=off,table_elimination=on,extended_keys=off 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. 190423 20:30:13 mysqld_safe Number of processes running now: 0 190423 20:30:13 mysqld_safe mysqld restarted 190423 20:30:14 [Note] /usr/libexec/mysqld (mysqld 5.5.60-MariaDB) starting as process 27068 ... 190423 20:30:14 InnoDB: The InnoDB memory heap is disabled 190423 20:30:14 InnoDB: Mutexes and rw_locks use GCC atomic builtins 190423 20:30:14 InnoDB: Compressed tables use zlib 1.2.7 190423 20:30:14 InnoDB: Using Linux native AIO 190423 20:30:14 InnoDB: Initializing buffer pool, size = 128.0M 190423 20:30:14 InnoDB: Completed initialization of buffer pool 190423 20:30:14 InnoDB: highest supported file format is Barracuda. 190423 20:30:14 InnoDB: Starting crash recovery from checkpoint LSN=17323895 InnoDB: Restoring possible half-written data pages from the doublewrite buffer... 190423 20:30:14 InnoDB: Starting final batch to recover 3 pages from redo log 190423 20:30:14 InnoDB: Waiting for the background threads to start 190423 20:30:15 Percona XtraDB (http://www.percona.com) 5.5.59-MariaDB-38.11 started; log sequence number 17355125 190423 20:30:15 [Note] Plugin 'FEEDBACK' is disabled. 190423 20:30:15 [Note] Server socket created on IP: '0.0.0.0'. 190423 20:30:15 [Note] Event Scheduler: Loaded 0 events 190423 20:30:15 [Note] /usr/libexec/mysqld: ready for connections. Version: '5.5.60-MariaDB' socket: '/data/mysql/mysql.sock' port: 3306 MariaDB Server 190423 20:45:14 InnoDB: Assertion failure in thread 139714490558208 in file fut0lst.ic line 83 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: http://dev.mysql.com/doc/refman/5.5/en/forcing-innodb-recovery.html InnoDB: about forcing recovery. 190423 20:45:14 [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 http://kb.askmonty.org/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: 5.5.60-MariaDB key_buffer_size=134217728 read_buffer_size=131072 max_used_connections=3 max_threads=153 thread_count=1 It is possible that mysqld could use up to key_buffer_size + (read_buffer_size + sort_buffer_size)*max_threads = 466718 K bytes of memory Hope that's ok; if not, decrease some variables in the equation. Thread pointer: 0x55e6b851f8f0 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 = 0x7f11d0945d80 thread_stack 0x48000 /usr/libexec/mysqld(my_print_stacktrace+0x3d)[0x55e6b55aecbd] /usr/libexec/mysqld(handle_fatal_signal+0x515)[0x55e6b51c34a5] sigaction.c:0(__restore_rt)[0x7f11edbb85d0] :0(__GI_raise)[0x7f11ec2e2207] :0(__GI_abort)[0x7f11ec2e38f8] /usr/libexec/mysqld(+0x2d73b7)[0x55e6b4ff63b7] /usr/libexec/mysqld(+0x6f87d0)[0x55e6b54177d0] /usr/libexec/mysqld(+0x657ade)[0x55e6b5376ade] /usr/libexec/mysqld(+0x671153)[0x55e6b5390153] /usr/libexec/mysqld(+0x666faf)[0x55e6b5385faf] /usr/libexec/mysqld(+0x668d94)[0x55e6b5387d94] /usr/libexec/mysqld(+0x66a6c7)[0x55e6b53896c7] /usr/libexec/mysqld(+0x60a5a0)[0x55e6b53295a0] /usr/libexec/mysqld(+0x60b54b)[0x55e6b532a54b] /usr/libexec/mysqld(_Z19ha_commit_one_phaseP3THDb+0x80)[0x55e6b51c5ac0] /usr/libexec/mysqld(_Z15ha_commit_transP3THDb+0x356)[0x55e6b51c6236] /usr/libexec/mysqld(_Z17trans_commit_stmtP3THD+0x1b)[0x55e6b51593bb] /usr/libexec/mysqld(_Z21mysql_execute_commandP3THD+0x3dc)[0x55e6b50919ec] /usr/libexec/mysqld(_Z11mysql_parseP3THDPcjP12Parser_state+0x125)[0x55e6b5098445] /usr/libexec/mysqld(_Z16dispatch_command19enum_server_commandP3THDPcj+0x1750)[0x55e6b509a4a0] /usr/libexec/mysqld(_Z24do_handle_one_connectionP3THD+0x1c2)[0x55e6b514ca22] /usr/libexec/mysqld(handle_one_connection+0x4a)[0x55e6b514caca] pthread_create.c:0(start_thread)[0x7f11edbb0dd5] /lib64/libc.so.6(clone+0x6d)[0x7f11ec3a9ead] Trying to get some variables. Some pointers may be invalid and cause the dump to abort. Query (0x7f11a8004c18): UPDATE `ipaddresses` SET `lastSeen`='2019-04-23 20:45:02' WHERE `id`='5956' Connection ID (thread ID): 12 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=on,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=off,table_elimination=on,extended_keys=off 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. 190423 20:45:14 mysqld_safe Number of processes running now: 0 190423 20:45:14 mysqld_safe mysqld restarted 190423 20:45:14 [Note] /usr/libexec/mysqld (mysqld 5.5.60-MariaDB) starting as process 28510 ... 190423 20:45:14 InnoDB: The InnoDB memory heap is disabled 190423 20:45:14 InnoDB: Mutexes and rw_locks use GCC atomic builtins 190423 20:45:14 InnoDB: Compressed tables use zlib 1.2.7 190423 20:45:14 InnoDB: Using Linux native AIO 190423 20:45:14 InnoDB: Initializing buffer pool, size = 128.0M 190423 20:45:14 InnoDB: Completed initialization of buffer pool 190423 20:45:14 InnoDB: highest supported file format is Barracuda. 190423 20:45:14 InnoDB: Starting crash recovery from checkpoint LSN=17361123 InnoDB: Restoring possible half-written data pages from the doublewrite buffer... 190423 20:45:14 InnoDB: Starting final batch to recover 3 pages from redo log 190423 20:45:15 InnoDB: Waiting for the background threads to start 190423 20:45:16 Percona XtraDB (http://www.percona.com) 5.5.59-MariaDB-38.11 started; log sequence number 17392354 190423 20:45:16 [Note] Plugin 'FEEDBACK' is disabled. 190423 20:45:16 [Note] Server socket created on IP: '0.0.0.0'. 190423 20:45:16 [Note] Event Scheduler: Loaded 0 events 190423 20:45:16 [Note] /usr/libexec/mysqld: ready for connections. Version: '5.5.60-MariaDB' socket: '/data/mysql/mysql.sock' port: 3306 MariaDB Server 190423 21:00:13 InnoDB: Assertion failure in thread 140124056258304 in file fut0lst.ic line 83 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: http://dev.mysql.com/doc/refman/5.5/en/forcing-innodb-recovery.html InnoDB: about forcing recovery. 190423 21:00:13 [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 http://kb.askmonty.org/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: 5.5.60-MariaDB key_buffer_size=134217728 read_buffer_size=131072 max_used_connections=3 max_threads=153 thread_count=1 It is possible that mysqld could use up to key_buffer_size + (read_buffer_size + sort_buffer_size)*max_threads = 466718 K bytes of memory Hope that's ok; if not, decrease some variables in the equation. Thread pointer: 0x55760a50d8f0 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 = 0x7f712c98fd80 thread_stack 0x48000 /usr/libexec/mysqld(my_print_stacktrace+0x3d)[0x557608488cbd] /usr/libexec/mysqld(handle_fatal_signal+0x515)[0x55760809d4a5] sigaction.c:0(__restore_rt)[0x7f7149cc15d0] :0(__GI_raise)[0x7f71483eb207] :0(__GI_abort)[0x7f71483ec8f8] /usr/libexec/mysqld(+0x2d73b7)[0x557607ed03b7] /usr/libexec/mysqld(+0x6f87d0)[0x5576082f17d0] /usr/libexec/mysqld(+0x657ade)[0x557608250ade] /usr/libexec/mysqld(+0x671153)[0x55760826a153] /usr/libexec/mysqld(+0x666faf)[0x55760825ffaf] /usr/libexec/mysqld(+0x668d94)[0x557608261d94] /usr/libexec/mysqld(+0x66a6c7)[0x5576082636c7] /usr/libexec/mysqld(+0x60a5a0)[0x5576082035a0] /usr/libexec/mysqld(+0x60b54b)[0x55760820454b] /usr/libexec/mysqld(_Z19ha_commit_one_phaseP3THDb+0x80)[0x55760809fac0] /usr/libexec/mysqld(_Z15ha_commit_transP3THDb+0x356)[0x5576080a0236] /usr/libexec/mysqld(_Z17trans_commit_stmtP3THD+0x1b)[0x5576080333bb] /usr/libexec/mysqld(_Z21mysql_execute_commandP3THD+0x3dc)[0x557607f6b9ec] /usr/libexec/mysqld(_Z11mysql_parseP3THDPcjP12Parser_state+0x125)[0x557607f72445] /usr/libexec/mysqld(_Z16dispatch_command19enum_server_commandP3THDPcj+0x1750)[0x557607f744a0] /usr/libexec/mysqld(_Z24do_handle_one_connectionP3THD+0x1c2)[0x557608026a22] /usr/libexec/mysqld(handle_one_connection+0x4a)[0x557608026aca] pthread_create.c:0(start_thread)[0x7f7149cb9dd5] /lib64/libc.so.6(clone+0x6d)[0x7f71484b2ead] Trying to get some variables. Some pointers may be invalid and cause the dump to abort. Query (0x7f7104004c18): UPDATE `ipaddresses` SET `lastSeen`='2019-04-23 21:00:01' WHERE `id`='5956' Connection ID (thread ID): 12 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=on,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=off,table_elimination=on,extended_keys=off 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. 190423 21:00:13 mysqld_safe Number of processes running now: 0 190423 21:00:13 mysqld_safe mysqld restarted 190423 21:00:13 [Note] /usr/libexec/mysqld (mysqld 5.5.60-MariaDB) starting as process 30427 ... 190423 21:00:13 InnoDB: The InnoDB memory heap is disabled 190423 21:00:13 InnoDB: Mutexes and rw_locks use GCC atomic builtins 190423 21:00:13 InnoDB: Compressed tables use zlib 1.2.7 190423 21:00:13 InnoDB: Using Linux native AIO 190423 21:00:13 InnoDB: Initializing buffer pool, size = 128.0M 190423 21:00:13 InnoDB: Completed initialization of buffer pool 190423 21:00:13 InnoDB: highest supported file format is Barracuda. 190423 21:00:13 InnoDB: Starting crash recovery from checkpoint LSN=17401209 InnoDB: Restoring possible half-written data pages from the doublewrite buffer... 190423 21:00:13 InnoDB: Starting final batch to recover 3 pages from redo log 190423 21:00:14 InnoDB: Waiting for the background threads to start 190423 21:00:15 Percona XtraDB (http://www.percona.com) 5.5.59-MariaDB-38.11 started; log sequence number 17432494 190423 21:00:15 [Note] Plugin 'FEEDBACK' is disabled. 190423 21:00:15 [Note] Server socket created on IP: '0.0.0.0'. 190423 21:00:15 [Note] Event Scheduler: Loaded 0 events 190423 21:00:15 [Note] /usr/libexec/mysqld: ready for connections. Version: '5.5.60-MariaDB' socket: '/data/mysql/mysql.sock' port: 3306 MariaDB Server 190423 21:15:14 InnoDB: Assertion failure in thread 140279723706112 in file fut0lst.ic line 83 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: http://dev.mysql.com/doc/refman/5.5/en/forcing-innodb-recovery.html InnoDB: about forcing recovery. 190423 21:15:14 [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 http://kb.askmonty.org/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: 5.5.60-MariaDB key_buffer_size=134217728 read_buffer_size=131072 max_used_connections=3 max_threads=153 thread_count=1 It is possible that mysqld could use up to key_buffer_size + (read_buffer_size + sort_buffer_size)*max_threads = 466718 K bytes of memory Hope that's ok; if not, decrease some variables in the equation. Thread pointer: 0x561cc92723b0 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 = 0x7f956b19bd80 thread_stack 0x48000 /usr/libexec/mysqld(my_print_stacktrace+0x3d)[0x561cc625acbd] /usr/libexec/mysqld(handle_fatal_signal+0x515)[0x561cc5e6f4a5] sigaction.c:0(__restore_rt)[0x7f958840f5d0] :0(__GI_raise)[0x7f9586b39207] :0(__GI_abort)[0x7f9586b3a8f8] /usr/libexec/mysqld(+0x2d73b7)[0x561cc5ca23b7] /usr/libexec/mysqld(+0x6f87d0)[0x561cc60c37d0] /usr/libexec/mysqld(+0x657ade)[0x561cc6022ade] /usr/libexec/mysqld(+0x671153)[0x561cc603c153] /usr/libexec/mysqld(+0x666faf)[0x561cc6031faf] /usr/libexec/mysqld(+0x668d94)[0x561cc6033d94] /usr/libexec/mysqld(+0x66a6c7)[0x561cc60356c7] /usr/libexec/mysqld(+0x60a5a0)[0x561cc5fd55a0] /usr/libexec/mysqld(+0x60b54b)[0x561cc5fd654b] /usr/libexec/mysqld(_Z19ha_commit_one_phaseP3THDb+0x80)[0x561cc5e71ac0] /usr/libexec/mysqld(_Z15ha_commit_transP3THDb+0x356)[0x561cc5e72236] /usr/libexec/mysqld(_Z17trans_commit_stmtP3THD+0x1b)[0x561cc5e053bb] /usr/libexec/mysqld(_Z21mysql_execute_commandP3THD+0x3dc)[0x561cc5d3d9ec] /usr/libexec/mysqld(_Z11mysql_parseP3THDPcjP12Parser_state+0x125)[0x561cc5d44445] /usr/libexec/mysqld(_Z16dispatch_command19enum_server_commandP3THDPcj+0x1750)[0x561cc5d464a0] /usr/libexec/mysqld(_Z24do_handle_one_connectionP3THD+0x1c2)[0x561cc5df8a22] /usr/libexec/mysqld(handle_one_connection+0x4a)[0x561cc5df8aca] pthread_create.c:0(start_thread)[0x7f9588407dd5] /lib64/libc.so.6(clone+0x6d)[0x7f9586c00ead] Trying to get some variables. Some pointers may be invalid and cause the dump to abort. Query (0x7f9540004c18): UPDATE `ipaddresses` SET `lastSeen`='2019-04-23 21:15:02' WHERE `id`='5956' Connection ID (thread ID): 12 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=on,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=off,table_elimination=on,extended_keys=off 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. 190423 21:15:14 mysqld_safe Number of processes running now: 0 190423 21:15:14 mysqld_safe mysqld restarted 190423 21:15:14 [Note] /usr/libexec/mysqld (mysqld 5.5.60-MariaDB) starting as process 31889 ... 190423 21:15:14 InnoDB: The InnoDB memory heap is disabled 190423 21:15:14 InnoDB: Mutexes and rw_locks use GCC atomic builtins 190423 21:15:14 InnoDB: Compressed tables use zlib 1.2.7 190423 21:15:14 InnoDB: Using Linux native AIO 190423 21:15:14 InnoDB: Initializing buffer pool, size = 128.0M 190423 21:15:14 InnoDB: Completed initialization of buffer pool 190423 21:15:14 InnoDB: highest supported file format is Barracuda. 190423 21:15:14 InnoDB: Starting crash recovery from checkpoint LSN=17441327 InnoDB: Restoring possible half-written data pages from the doublewrite buffer... 190423 21:15:14 InnoDB: Starting final batch to recover 3 pages from redo log 190423 21:15:14 InnoDB: Waiting for the background threads to start 190423 21:15:15 Percona XtraDB (http://www.percona.com) 5.5.59-MariaDB-38.11 started; log sequence number 17474008 190423 21:15:15 [Note] Plugin 'FEEDBACK' is disabled. 190423 21:15:15 [Note] Server socket created on IP: '0.0.0.0'. 190423 21:15:15 [Note] Event Scheduler: Loaded 0 events 190423 21:15:15 [Note] /usr/libexec/mysqld: ready for connections. Version: '5.5.60-MariaDB' socket: '/data/mysql/mysql.sock' port: 3306 MariaDB Server 190423 21:30:13 InnoDB: Assertion failure in thread 140680850708224 in file fut0lst.ic line 83 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: http://dev.mysql.com/doc/refman/5.5/en/forcing-innodb-recovery.html InnoDB: about forcing recovery. 190423 21:30:13 [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 http://kb.askmonty.org/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: 5.5.60-MariaDB key_buffer_size=134217728 read_buffer_size=131072 max_used_connections=3 max_threads=153 thread_count=1 It is possible that mysqld could use up to key_buffer_size + (read_buffer_size + sort_buffer_size)*max_threads = 466718 K bytes of memory Hope that's ok; if not, decrease some variables in the equation. Thread pointer: 0x556e33108af0 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 = 0x7ff2d0220d80 thread_stack 0x48000 /usr/libexec/mysqld(my_print_stacktrace+0x3d)[0x556e30577cbd] /usr/libexec/mysqld(handle_fatal_signal+0x515)[0x556e3018c4a5] sigaction.c:0(__restore_rt)[0x7ff2d41275d0] :0(__GI_raise)[0x7ff2d2851207] :0(__GI_abort)[0x7ff2d28528f8] /usr/libexec/mysqld(+0x2d73b7)[0x556e2ffbf3b7] /usr/libexec/mysqld(+0x6f87d0)[0x556e303e07d0] /usr/libexec/mysqld(+0x657ade)[0x556e3033fade] /usr/libexec/mysqld(+0x671153)[0x556e30359153] /usr/libexec/mysqld(+0x666faf)[0x556e3034efaf] /usr/libexec/mysqld(+0x668d94)[0x556e30350d94] /usr/libexec/mysqld(+0x66a6c7)[0x556e303526c7] /usr/libexec/mysqld(+0x60a5a0)[0x556e302f25a0] /usr/libexec/mysqld(+0x60b54b)[0x556e302f354b] /usr/libexec/mysqld(_Z19ha_commit_one_phaseP3THDb+0x80)[0x556e3018eac0] /usr/libexec/mysqld(_Z15ha_commit_transP3THDb+0x356)[0x556e3018f236] /usr/libexec/mysqld(_Z17trans_commit_stmtP3THD+0x1b)[0x556e301223bb] /usr/libexec/mysqld(_Z21mysql_execute_commandP3THD+0x3dc)[0x556e3005a9ec] /usr/libexec/mysqld(_Z11mysql_parseP3THDPcjP12Parser_state+0x125)[0x556e30061445] /usr/libexec/mysqld(_Z16dispatch_command19enum_server_commandP3THDPcj+0x1750)[0x556e300634a0] /usr/libexec/mysqld(_Z24do_handle_one_connectionP3THD+0x1c2)[0x556e30115a22] /usr/libexec/mysqld(handle_one_connection+0x4a)[0x556e30115aca] pthread_create.c:0(start_thread)[0x7ff2d411fdd5] /lib64/libc.so.6(clone+0x6d)[0x7ff2d2918ead] Trying to get some variables. Some pointers may be invalid and cause the dump to abort. Query (0x7ff28c004c18): UPDATE `ipaddresses` SET `lastSeen`='2019-04-23 21:30:01' WHERE `id`='5956' Connection ID (thread ID): 12 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=on,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=off,table_elimination=on,extended_keys=off 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. 190423 21:30:14 mysqld_safe Number of processes running now: 0 190423 21:30:14 mysqld_safe mysqld restarted 190423 21:30:14 [Note] /usr/libexec/mysqld (mysqld 5.5.60-MariaDB) starting as process 1349 ... 190423 21:30:14 InnoDB: The InnoDB memory heap is disabled 190423 21:30:14 InnoDB: Mutexes and rw_locks use GCC atomic builtins 190423 21:30:14 InnoDB: Compressed tables use zlib 1.2.7 190423 21:30:14 InnoDB: Using Linux native AIO 190423 21:30:14 InnoDB: Initializing buffer pool, size = 128.0M 190423 21:30:14 InnoDB: Completed initialization of buffer pool 190423 21:30:14 InnoDB: highest supported file format is Barracuda. 190423 21:30:14 InnoDB: Starting crash recovery from checkpoint LSN=17480009 InnoDB: Restoring possible half-written data pages from the doublewrite buffer... 190423 21:30:14 InnoDB: Starting final batch to recover 2 pages from redo log 190423 21:30:14 InnoDB: Waiting for the background threads to start 190423 21:30:15 Percona XtraDB (http://www.percona.com) 5.5.59-MariaDB-38.11 started; log sequence number 17510493 190423 21:30:15 [Note] Plugin 'FEEDBACK' is disabled. 190423 21:30:15 [Note] Server socket created on IP: '0.0.0.0'. 190423 21:30:15 [Note] Event Scheduler: Loaded 0 events 190423 21:30:15 [Note] /usr/libexec/mysqld: ready for connections. Version: '5.5.60-MariaDB' socket: '/data/mysql/mysql.sock' port: 3306 MariaDB Server 190423 21:45:14 InnoDB: Assertion failure in thread 140437849032448 in file fut0lst.ic line 83 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: http://dev.mysql.com/doc/refman/5.5/en/forcing-innodb-recovery.html InnoDB: about forcing recovery. 190423 21:45:14 [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 http://kb.askmonty.org/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: 5.5.60-MariaDB key_buffer_size=134217728 read_buffer_size=131072 max_used_connections=3 max_threads=153 thread_count=1 It is possible that mysqld could use up to key_buffer_size + (read_buffer_size + sort_buffer_size)*max_threads = 466718 K bytes of memory Hope that's ok; if not, decrease some variables in the equation. Thread pointer: 0x56241afe3ab0 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 = 0x7fba3c1abd80 thread_stack 0x48000 /usr/libexec/mysqld(my_print_stacktrace+0x3d)[0x5624181ffcbd] /usr/libexec/mysqld(handle_fatal_signal+0x515)[0x562417e144a5] sigaction.c:0(__restore_rt)[0x7fba4280c5d0] :0(__GI_raise)[0x7fba40f36207] :0(__GI_abort)[0x7fba40f378f8] /usr/libexec/mysqld(+0x2d73b7)[0x562417c473b7] /usr/libexec/mysqld(+0x6f87d0)[0x5624180687d0] /usr/libexec/mysqld(+0x657ade)[0x562417fc7ade] /usr/libexec/mysqld(+0x671153)[0x562417fe1153] /usr/libexec/mysqld(+0x666faf)[0x562417fd6faf] /usr/libexec/mysqld(+0x668d94)[0x562417fd8d94] /usr/libexec/mysqld(+0x66a6c7)[0x562417fda6c7] /usr/libexec/mysqld(+0x60a5a0)[0x562417f7a5a0] /usr/libexec/mysqld(+0x60b54b)[0x562417f7b54b] /usr/libexec/mysqld(_Z19ha_commit_one_phaseP3THDb+0x80)[0x562417e16ac0] /usr/libexec/mysqld(_Z15ha_commit_transP3THDb+0x356)[0x562417e17236] /usr/libexec/mysqld(_Z17trans_commit_stmtP3THD+0x1b)[0x562417daa3bb] /usr/libexec/mysqld(_Z21mysql_execute_commandP3THD+0x3dc)[0x562417ce29ec] /usr/libexec/mysqld(_Z11mysql_parseP3THDPcjP12Parser_state+0x125)[0x562417ce9445] /usr/libexec/mysqld(_Z16dispatch_command19enum_server_commandP3THDPcj+0x1750)[0x562417ceb4a0] /usr/libexec/mysqld(_Z24do_handle_one_connectionP3THD+0x1c2)[0x562417d9da22] /usr/libexec/mysqld(handle_one_connection+0x4a)[0x562417d9daca] pthread_create.c:0(start_thread)[0x7fba42804dd5] /lib64/libc.so.6(clone+0x6d)[0x7fba40ffdead] Trying to get some variables. Some pointers may be invalid and cause the dump to abort. Query (0x7fb9fc004c18): UPDATE `ipaddresses` SET `lastSeen`='2019-04-23 21:45:02' WHERE `id`='5956' Connection ID (thread ID): 12 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=on,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=off,table_elimination=on,extended_keys=off 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. 190423 21:45:14 mysqld_safe Number of processes running now: 0 190423 21:45:14 mysqld_safe mysqld restarted 190423 21:45:14 [Note] /usr/libexec/mysqld (mysqld 5.5.60-MariaDB) starting as process 2872 ... 190423 21:45:14 InnoDB: The InnoDB memory heap is disabled 190423 21:45:14 InnoDB: Mutexes and rw_locks use GCC atomic builtins 190423 21:45:14 InnoDB: Compressed tables use zlib 1.2.7 190423 21:45:14 InnoDB: Using Linux native AIO 190423 21:45:14 InnoDB: Initializing buffer pool, size = 128.0M 190423 21:45:14 InnoDB: Completed initialization of buffer pool 190423 21:45:14 InnoDB: highest supported file format is Barracuda. 190423 21:45:14 InnoDB: Starting crash recovery from checkpoint LSN=17516371 InnoDB: Restoring possible half-written data pages from the doublewrite buffer... 190423 21:45:14 InnoDB: Starting final batch to recover 2 pages from redo log 190423 21:45:14 InnoDB: Waiting for the background threads to start 190423 21:45:15 Percona XtraDB (http://www.percona.com) 5.5.59-MariaDB-38.11 started; log sequence number 17546856 190423 21:45:15 [Note] Plugin 'FEEDBACK' is disabled. 190423 21:45:15 [Note] Server socket created on IP: '0.0.0.0'. 190423 21:45:15 [Note] Event Scheduler: Loaded 0 events 190423 21:45:15 [Note] /usr/libexec/mysqld: ready for connections. Version: '5.5.60-MariaDB' socket: '/data/mysql/mysql.sock' port: 3306 MariaDB Server 190423 22:00:13 InnoDB: Assertion failure in thread 139879469324032 in file fut0lst.ic line 83 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: http://dev.mysql.com/doc/refman/5.5/en/forcing-innodb-recovery.html InnoDB: about forcing recovery. 190423 22:00:13 [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 http://kb.askmonty.org/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: 5.5.60-MariaDB key_buffer_size=134217728 read_buffer_size=131072 max_used_connections=3 max_threads=153 thread_count=1 It is possible that mysqld could use up to key_buffer_size + (read_buffer_size + sort_buffer_size)*max_threads = 466718 K bytes of memory Hope that's ok; if not, decrease some variables in the equation. Thread pointer: 0x55f8f490aab0 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 = 0x7f383a148d80 thread_stack 0x48000 /usr/libexec/mysqld(my_print_stacktrace+0x3d)[0x55f8f12aecbd] /usr/libexec/mysqld(handle_fatal_signal+0x515)[0x55f8f0ec34a5] sigaction.c:0(__restore_rt)[0x7f38573ff5d0] :0(__GI_raise)[0x7f3855b29207] :0(__GI_abort)[0x7f3855b2a8f8] /usr/libexec/mysqld(+0x2d73b7)[0x55f8f0cf63b7] /usr/libexec/mysqld(+0x6f87d0)[0x55f8f11177d0] /usr/libexec/mysqld(+0x657ade)[0x55f8f1076ade] /usr/libexec/mysqld(+0x671153)[0x55f8f1090153] /usr/libexec/mysqld(+0x666faf)[0x55f8f1085faf] /usr/libexec/mysqld(+0x668d94)[0x55f8f1087d94] /usr/libexec/mysqld(+0x66a6c7)[0x55f8f10896c7] /usr/libexec/mysqld(+0x60a5a0)[0x55f8f10295a0] /usr/libexec/mysqld(+0x60b54b)[0x55f8f102a54b] /usr/libexec/mysqld(_Z19ha_commit_one_phaseP3THDb+0x80)[0x55f8f0ec5ac0] /usr/libexec/mysqld(_Z15ha_commit_transP3THDb+0x356)[0x55f8f0ec6236] /usr/libexec/mysqld(_Z17trans_commit_stmtP3THD+0x1b)[0x55f8f0e593bb] /usr/libexec/mysqld(_Z21mysql_execute_commandP3THD+0x3dc)[0x55f8f0d919ec] /usr/libexec/mysqld(_Z11mysql_parseP3THDPcjP12Parser_state+0x125)[0x55f8f0d98445] /usr/libexec/mysqld(_Z16dispatch_command19enum_server_commandP3THDPcj+0x1750)[0x55f8f0d9a4a0] /usr/libexec/mysqld(_Z24do_handle_one_connectionP3THD+0x1c2)[0x55f8f0e4ca22] /usr/libexec/mysqld(handle_one_connection+0x4a)[0x55f8f0e4caca] pthread_create.c:0(start_thread)[0x7f38573f7dd5] /lib64/libc.so.6(clone+0x6d)[0x7f3855bf0ead] Trying to get some variables. Some pointers may be invalid and cause the dump to abort. Query (0x7f3810004c18): UPDATE `ipaddresses` SET `lastSeen`='2019-04-23 22:00:01' WHERE `id`='5956' Connection ID (thread ID): 12 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=on,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=off,table_elimination=on,extended_keys=off 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. 190423 22:00:14 mysqld_safe Number of processes running now: 0 190423 22:00:14 mysqld_safe mysqld restarted 190423 22:00:14 [Note] /usr/libexec/mysqld (mysqld 5.5.60-MariaDB) starting as process 4880 ... 190423 22:00:14 InnoDB: The InnoDB memory heap is disabled 190423 22:00:14 InnoDB: Mutexes and rw_locks use GCC atomic builtins 190423 22:00:14 InnoDB: Compressed tables use zlib 1.2.7 190423 22:00:14 InnoDB: Using Linux native AIO 190423 22:00:14 InnoDB: Initializing buffer pool, size = 128.0M 190423 22:00:14 InnoDB: Completed initialization of buffer pool 190423 22:00:14 InnoDB: highest supported file format is Barracuda. 190423 22:00:14 InnoDB: Starting crash recovery from checkpoint LSN=17552852 InnoDB: Restoring possible half-written data pages from the doublewrite buffer... 190423 22:00:14 InnoDB: Starting final batch to recover 2 pages from redo log 190423 22:00:14 InnoDB: Waiting for the background threads to start 190423 22:00:15 Percona XtraDB (http://www.percona.com) 5.5.59-MariaDB-38.11 started; log sequence number 17583337 190423 22:00:15 [Note] Plugin 'FEEDBACK' is disabled. 190423 22:00:15 [Note] Server socket created on IP: '0.0.0.0'. 190423 22:00:15 [Note] Event Scheduler: Loaded 0 events 190423 22:00:15 [Note] /usr/libexec/mysqld: ready for connections. Version: '5.5.60-MariaDB' socket: '/data/mysql/mysql.sock' port: 3306 MariaDB Server 190423 22:15:14 InnoDB: Assertion failure in thread 139701667030784 in file fut0lst.ic line 83 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: http://dev.mysql.com/doc/refman/5.5/en/forcing-innodb-recovery.html InnoDB: about forcing recovery. 190423 22:15:14 [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 http://kb.askmonty.org/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: 5.5.60-MariaDB key_buffer_size=134217728 read_buffer_size=131072 max_used_connections=3 max_threads=153 thread_count=1 It is possible that mysqld could use up to key_buffer_size + (read_buffer_size + sort_buffer_size)*max_threads = 466718 K bytes of memory Hope that's ok; if not, decrease some variables in the equation. Thread pointer: 0x5556c0643ab0 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 = 0x7f0ed43cdd80 thread_stack 0x48000 /usr/libexec/mysqld(my_print_stacktrace+0x3d)[0x5556be7c9cbd] /usr/libexec/mysqld(handle_fatal_signal+0x515)[0x5556be3de4a5] sigaction.c:0(__restore_rt)[0x7f0edb22f5d0] :0(__GI_raise)[0x7f0ed9959207] :0(__GI_abort)[0x7f0ed995a8f8] /usr/libexec/mysqld(+0x2d73b7)[0x5556be2113b7] /usr/libexec/mysqld(+0x6f87d0)[0x5556be6327d0] /usr/libexec/mysqld(+0x657ade)[0x5556be591ade] /usr/libexec/mysqld(+0x671153)[0x5556be5ab153] /usr/libexec/mysqld(+0x666faf)[0x5556be5a0faf] /usr/libexec/mysqld(+0x668d94)[0x5556be5a2d94] /usr/libexec/mysqld(+0x66a6c7)[0x5556be5a46c7] /usr/libexec/mysqld(+0x60a5a0)[0x5556be5445a0] /usr/libexec/mysqld(+0x60b54b)[0x5556be54554b] /usr/libexec/mysqld(_Z19ha_commit_one_phaseP3THDb+0x80)[0x5556be3e0ac0] /usr/libexec/mysqld(_Z15ha_commit_transP3THDb+0x356)[0x5556be3e1236] /usr/libexec/mysqld(_Z17trans_commit_stmtP3THD+0x1b)[0x5556be3743bb] /usr/libexec/mysqld(_Z21mysql_execute_commandP3THD+0x3dc)[0x5556be2ac9ec] /usr/libexec/mysqld(_Z11mysql_parseP3THDPcjP12Parser_state+0x125)[0x5556be2b3445] /usr/libexec/mysqld(_Z16dispatch_command19enum_server_commandP3THDPcj+0x1750)[0x5556be2b54a0] /usr/libexec/mysqld(_Z24do_handle_one_connectionP3THD+0x1c2)[0x5556be367a22] /usr/libexec/mysqld(handle_one_connection+0x4a)[0x5556be367aca] pthread_create.c:0(start_thread)[0x7f0edb227dd5] /lib64/libc.so.6(clone+0x6d)[0x7f0ed9a20ead] Trying to get some variables. Some pointers may be invalid and cause the dump to abort. Query (0x7f0e94004c18): UPDATE `ipaddresses` SET `lastSeen`='2019-04-23 22:15:02' WHERE `id`='5956' Connection ID (thread ID): 12 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=on,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=off,table_elimination=on,extended_keys=off 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. 190423 22:15:14 mysqld_safe Number of processes running now: 0 190423 22:15:14 mysqld_safe mysqld restarted 190423 22:15:14 [Note] /usr/libexec/mysqld (mysqld 5.5.60-MariaDB) starting as process 6363 ... 190423 22:15:14 InnoDB: The InnoDB memory heap is disabled 190423 22:15:14 InnoDB: Mutexes and rw_locks use GCC atomic builtins 190423 22:15:14 InnoDB: Compressed tables use zlib 1.2.7 190423 22:15:14 InnoDB: Using Linux native AIO 190423 22:15:14 InnoDB: Initializing buffer pool, size = 128.0M 190423 22:15:14 InnoDB: Completed initialization of buffer pool 190423 22:15:14 InnoDB: highest supported file format is Barracuda. 190423 22:15:14 InnoDB: Starting crash recovery from checkpoint LSN=17589215 InnoDB: Restoring possible half-written data pages from the doublewrite buffer... 190423 22:15:14 InnoDB: Starting final batch to recover 2 pages from redo log 190423 22:15:15 InnoDB: Waiting for the background threads to start 190423 22:15:16 Percona XtraDB (http://www.percona.com) 5.5.59-MariaDB-38.11 started; log sequence number 17619734 190423 22:15:16 [Note] Plugin 'FEEDBACK' is disabled. 190423 22:15:16 [Note] Server socket created on IP: '0.0.0.0'. 190423 22:15:16 [Note] Event Scheduler: Loaded 0 events 190423 22:15:16 [Note] /usr/libexec/mysqld: ready for connections. Version: '5.5.60-MariaDB' socket: '/data/mysql/mysql.sock' port: 3306 MariaDB Server 190423 22:30:13 InnoDB: Assertion failure in thread 140131834214144 in file fut0lst.ic line 83 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: http://dev.mysql.com/doc/refman/5.5/en/forcing-innodb-recovery.html InnoDB: about forcing recovery. 190423 22:30:13 [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 http://kb.askmonty.org/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: 5.5.60-MariaDB key_buffer_size=134217728 read_buffer_size=131072 max_used_connections=3 max_threads=153 thread_count=1 It is possible that mysqld could use up to key_buffer_size + (read_buffer_size + sort_buffer_size)*max_threads = 466718 K bytes of memory Hope that's ok; if not, decrease some variables in the equation. Thread pointer: 0x55b6ed494730 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 = 0x7f72fc332d80 thread_stack 0x48000 /usr/libexec/mysqld(my_print_stacktrace+0x3d)[0x55b6ea780cbd] /usr/libexec/mysqld(handle_fatal_signal+0x515)[0x55b6ea3954a5] sigaction.c:0(__restore_rt)[0x7f73031945d0] :0(__GI_raise)[0x7f73018be207] :0(__GI_abort)[0x7f73018bf8f8] /usr/libexec/mysqld(+0x2d73b7)[0x55b6ea1c83b7] /usr/libexec/mysqld(+0x6f87d0)[0x55b6ea5e97d0] /usr/libexec/mysqld(+0x657ade)[0x55b6ea548ade] /usr/libexec/mysqld(+0x671153)[0x55b6ea562153] /usr/libexec/mysqld(+0x666faf)[0x55b6ea557faf] /usr/libexec/mysqld(+0x668d94)[0x55b6ea559d94] /usr/libexec/mysqld(+0x66a6c7)[0x55b6ea55b6c7] /usr/libexec/mysqld(+0x60a5a0)[0x55b6ea4fb5a0] /usr/libexec/mysqld(+0x60b54b)[0x55b6ea4fc54b] /usr/libexec/mysqld(_Z19ha_commit_one_phaseP3THDb+0x80)[0x55b6ea397ac0] /usr/libexec/mysqld(_Z15ha_commit_transP3THDb+0x356)[0x55b6ea398236] /usr/libexec/mysqld(_Z17trans_commit_stmtP3THD+0x1b)[0x55b6ea32b3bb] /usr/libexec/mysqld(_Z21mysql_execute_commandP3THD+0x3dc)[0x55b6ea2639ec] /usr/libexec/mysqld(_Z11mysql_parseP3THDPcjP12Parser_state+0x125)[0x55b6ea26a445] /usr/libexec/mysqld(_Z16dispatch_command19enum_server_commandP3THDPcj+0x1750)[0x55b6ea26c4a0] /usr/libexec/mysqld(_Z24do_handle_one_connectionP3THD+0x1c2)[0x55b6ea31ea22] /usr/libexec/mysqld(handle_one_connection+0x4a)[0x55b6ea31eaca] pthread_create.c:0(start_thread)[0x7f730318cdd5] /lib64/libc.so.6(clone+0x6d)[0x7f7301985ead] Trying to get some variables. Some pointers may be invalid and cause the dump to abort. Query (0x7f72bc004c18): UPDATE `ipaddresses` SET `lastSeen`='2019-04-23 22:30:01' WHERE `id`='5956' Connection ID (thread ID): 12 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=on,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=off,table_elimination=on,extended_keys=off 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. 190423 22:30:13 mysqld_safe Number of processes running now: 0 190423 22:30:13 mysqld_safe mysqld restarted 190423 22:30:13 [Note] /usr/libexec/mysqld (mysqld 5.5.60-MariaDB) starting as process 8310 ... 190423 22:30:13 InnoDB: The InnoDB memory heap is disabled 190423 22:30:13 InnoDB: Mutexes and rw_locks use GCC atomic builtins 190423 22:30:13 InnoDB: Compressed tables use zlib 1.2.7 190423 22:30:13 InnoDB: Using Linux native AIO 190423 22:30:13 InnoDB: Initializing buffer pool, size = 128.0M 190423 22:30:13 InnoDB: Completed initialization of buffer pool 190423 22:30:13 InnoDB: highest supported file format is Barracuda. 190423 22:30:13 InnoDB: Starting crash recovery from checkpoint LSN=17625846 InnoDB: Restoring possible half-written data pages from the doublewrite buffer... 190423 22:30:14 InnoDB: Starting final batch to recover 3 pages from redo log 190423 22:30:14 InnoDB: Waiting for the background threads to start 190423 22:30:15 Percona XtraDB (http://www.percona.com) 5.5.59-MariaDB-38.11 started; log sequence number 17657848 190423 22:30:15 [Note] Plugin 'FEEDBACK' is disabled. 190423 22:30:15 [Note] Server socket created on IP: '0.0.0.0'. 190423 22:30:15 [Note] Event Scheduler: Loaded 0 events 190423 22:30:15 [Note] /usr/libexec/mysqld: ready for connections. Version: '5.5.60-MariaDB' socket: '/data/mysql/mysql.sock' port: 3306 MariaDB Server 190423 22:45:14 InnoDB: Assertion failure in thread 139891314542336 in file fut0lst.ic line 83 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: http://dev.mysql.com/doc/refman/5.5/en/forcing-innodb-recovery.html InnoDB: about forcing recovery. 190423 22:45:14 [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 http://kb.askmonty.org/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: 5.5.60-MariaDB key_buffer_size=134217728 read_buffer_size=131072 max_used_connections=3 max_threads=153 thread_count=1 It is possible that mysqld could use up to key_buffer_size + (read_buffer_size + sort_buffer_size)*max_threads = 466718 K bytes of memory Hope that's ok; if not, decrease some variables in the equation. Thread pointer: 0x558ad47c5570 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 = 0x7f3afc1c3d80 thread_stack 0x48000 /usr/libexec/mysqld(my_print_stacktrace+0x3d)[0x558ad2615cbd] /usr/libexec/mysqld(handle_fatal_signal+0x515)[0x558ad222a4a5] sigaction.c:0(__restore_rt)[0x7f3b0286e5d0] :0(__GI_raise)[0x7f3b00f98207] :0(__GI_abort)[0x7f3b00f998f8] /usr/libexec/mysqld(+0x2d73b7)[0x558ad205d3b7] /usr/libexec/mysqld(+0x6f87d0)[0x558ad247e7d0] /usr/libexec/mysqld(+0x657ade)[0x558ad23ddade] /usr/libexec/mysqld(+0x671153)[0x558ad23f7153] /usr/libexec/mysqld(+0x666faf)[0x558ad23ecfaf] /usr/libexec/mysqld(+0x668d94)[0x558ad23eed94] /usr/libexec/mysqld(+0x66a6c7)[0x558ad23f06c7] /usr/libexec/mysqld(+0x60a5a0)[0x558ad23905a0] /usr/libexec/mysqld(+0x60b54b)[0x558ad239154b] /usr/libexec/mysqld(_Z19ha_commit_one_phaseP3THDb+0x80)[0x558ad222cac0] /usr/libexec/mysqld(_Z15ha_commit_transP3THDb+0x356)[0x558ad222d236] /usr/libexec/mysqld(_Z17trans_commit_stmtP3THD+0x1b)[0x558ad21c03bb] /usr/libexec/mysqld(_Z21mysql_execute_commandP3THD+0x3dc)[0x558ad20f89ec] /usr/libexec/mysqld(_Z11mysql_parseP3THDPcjP12Parser_state+0x125)[0x558ad20ff445] /usr/libexec/mysqld(_Z16dispatch_command19enum_server_commandP3THDPcj+0x1750)[0x558ad21014a0] /usr/libexec/mysqld(_Z24do_handle_one_connectionP3THD+0x1c2)[0x558ad21b3a22] /usr/libexec/mysqld(handle_one_connection+0x4a)[0x558ad21b3aca] pthread_create.c:0(start_thread)[0x7f3b02866dd5] /lib64/libc.so.6(clone+0x6d)[0x7f3b0105fead] Trying to get some variables. Some pointers may be invalid and cause the dump to abort. Query (0x7f3abc004c18): UPDATE `ipaddresses` SET `lastSeen`='2019-04-23 22:45:02' WHERE `id`='5956' Connection ID (thread ID): 12 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=on,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=off,table_elimination=on,extended_keys=off 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. 190423 22:45:14 mysqld_safe Number of processes running now: 0 190423 22:45:14 mysqld_safe mysqld restarted 190423 22:45:14 [Note] /usr/libexec/mysqld (mysqld 5.5.60-MariaDB) starting as process 9769 ... 190423 22:45:14 InnoDB: The InnoDB memory heap is disabled 190423 22:45:14 InnoDB: Mutexes and rw_locks use GCC atomic builtins 190423 22:45:14 InnoDB: Compressed tables use zlib 1.2.7 190423 22:45:14 InnoDB: Using Linux native AIO 190423 22:45:14 InnoDB: Initializing buffer pool, size = 128.0M 190423 22:45:14 InnoDB: Completed initialization of buffer pool 190423 22:45:14 InnoDB: highest supported file format is Barracuda. 190423 22:45:14 InnoDB: Starting crash recovery from checkpoint LSN=17664293 InnoDB: Restoring possible half-written data pages from the doublewrite buffer... 190423 22:45:14 InnoDB: Starting final batch to recover 3 pages from redo log 190423 22:45:14 InnoDB: Waiting for the background threads to start 190423 22:45:15 Percona XtraDB (http://www.percona.com) 5.5.59-MariaDB-38.11 started; log sequence number 17697027 190423 22:45:15 [Note] Plugin 'FEEDBACK' is disabled. 190423 22:45:16 [Note] Server socket created on IP: '0.0.0.0'. 190423 22:45:16 [Note] Event Scheduler: Loaded 0 events 190423 22:45:16 [Note] /usr/libexec/mysqld: ready for connections. Version: '5.5.60-MariaDB' socket: '/data/mysql/mysql.sock' port: 3306 MariaDB Server 190423 23:00:13 InnoDB: Assertion failure in thread 140169482200832 in file fut0lst.ic line 83 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: http://dev.mysql.com/doc/refman/5.5/en/forcing-innodb-recovery.html InnoDB: about forcing recovery. 190423 23:00:13 [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 http://kb.askmonty.org/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: 5.5.60-MariaDB key_buffer_size=134217728 read_buffer_size=131072 max_used_connections=3 max_threads=153 thread_count=1 It is possible that mysqld could use up to key_buffer_size + (read_buffer_size + sort_buffer_size)*max_threads = 466718 K bytes of memory Hope that's ok; if not, decrease some variables in the equation. Thread pointer: 0x55d63a742730 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 = 0x7f7bc031dd80 thread_stack 0x48000 /usr/libexec/mysqld(my_print_stacktrace+0x3d)[0x55d637443cbd] /usr/libexec/mysqld(handle_fatal_signal+0x515)[0x55d6370584a5] sigaction.c:0(__restore_rt)[0x7f7bc776d5d0] :0(__GI_raise)[0x7f7bc5e97207] :0(__GI_abort)[0x7f7bc5e988f8] /usr/libexec/mysqld(+0x2d73b7)[0x55d636e8b3b7] /usr/libexec/mysqld(+0x6f87d0)[0x55d6372ac7d0] /usr/libexec/mysqld(+0x657ade)[0x55d63720bade] /usr/libexec/mysqld(+0x671153)[0x55d637225153] /usr/libexec/mysqld(+0x666faf)[0x55d63721afaf] /usr/libexec/mysqld(+0x668d94)[0x55d63721cd94] /usr/libexec/mysqld(+0x66a6c7)[0x55d63721e6c7] /usr/libexec/mysqld(+0x60a5a0)[0x55d6371be5a0] /usr/libexec/mysqld(+0x60b54b)[0x55d6371bf54b] /usr/libexec/mysqld(_Z19ha_commit_one_phaseP3THDb+0x80)[0x55d63705aac0] /usr/libexec/mysqld(_Z15ha_commit_transP3THDb+0x356)[0x55d63705b236] /usr/libexec/mysqld(_Z17trans_commit_stmtP3THD+0x1b)[0x55d636fee3bb] /usr/libexec/mysqld(_Z21mysql_execute_commandP3THD+0x3dc)[0x55d636f269ec] /usr/libexec/mysqld(_Z11mysql_parseP3THDPcjP12Parser_state+0x125)[0x55d636f2d445] /usr/libexec/mysqld(_Z16dispatch_command19enum_server_commandP3THDPcj+0x1750)[0x55d636f2f4a0] /usr/libexec/mysqld(_Z24do_handle_one_connectionP3THD+0x1c2)[0x55d636fe1a22] /usr/libexec/mysqld(handle_one_connection+0x4a)[0x55d636fe1aca] pthread_create.c:0(start_thread)[0x7f7bc7765dd5] /lib64/libc.so.6(clone+0x6d)[0x7f7bc5f5eead] Trying to get some variables. Some pointers may be invalid and cause the dump to abort. Query (0x7f7b80004c18): UPDATE `ipaddresses` SET `lastSeen`='2019-04-23 23:00:01' WHERE `id`='5956' Connection ID (thread ID): 12 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=on,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=off,table_elimination=on,extended_keys=off 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. 190423 23:00:13 mysqld_safe Number of processes running now: 0 190423 23:00:13 mysqld_safe mysqld restarted 190423 23:00:13 [Note] /usr/libexec/mysqld (mysqld 5.5.60-MariaDB) starting as process 11702 ... 190423 23:00:13 InnoDB: The InnoDB memory heap is disabled 190423 23:00:13 InnoDB: Mutexes and rw_locks use GCC atomic builtins 190423 23:00:13 InnoDB: Compressed tables use zlib 1.2.7 190423 23:00:13 InnoDB: Using Linux native AIO 190423 23:00:13 InnoDB: Initializing buffer pool, size = 128.0M 190423 23:00:13 InnoDB: Completed initialization of buffer pool 190423 23:00:13 InnoDB: highest supported file format is Barracuda. 190423 23:00:13 InnoDB: Starting crash recovery from checkpoint LSN=17703351 InnoDB: Restoring possible half-written data pages from the doublewrite buffer... 190423 23:00:13 InnoDB: Starting final batch to recover 3 pages from redo log 190423 23:00:14 InnoDB: Waiting for the background threads to start 190423 23:00:15 Percona XtraDB (http://www.percona.com) 5.5.59-MariaDB-38.11 started; log sequence number 17735369 190423 23:00:15 [Note] Plugin 'FEEDBACK' is disabled. 190423 23:00:15 [Note] Server socket created on IP: '0.0.0.0'. 190423 23:00:15 [Note] Event Scheduler: Loaded 0 events 190423 23:00:15 [Note] /usr/libexec/mysqld: ready for connections. Version: '5.5.60-MariaDB' socket: '/data/mysql/mysql.sock' port: 3306 MariaDB Server 190423 23:15:13 InnoDB: Assertion failure in thread 139640366610176 in file fut0lst.ic line 83 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: http://dev.mysql.com/doc/refman/5.5/en/forcing-innodb-recovery.html InnoDB: about forcing recovery. 190423 23:15:13 [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 http://kb.askmonty.org/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: 5.5.60-MariaDB key_buffer_size=134217728 read_buffer_size=131072 max_used_connections=3 max_threads=153 thread_count=1 It is possible that mysqld could use up to key_buffer_size + (read_buffer_size + sort_buffer_size)*max_threads = 466718 K bytes of memory Hope that's ok; if not, decrease some variables in the equation. Thread pointer: 0x55a6a686d570 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 = 0x7f008e72ad80 thread_stack 0x48000 /usr/libexec/mysqld(my_print_stacktrace+0x3d)[0x55a6a4967cbd] /usr/libexec/mysqld(handle_fatal_signal+0x515)[0x55a6a457c4a5] sigaction.c:0(__restore_rt)[0x7f00ab99d5d0] :0(__GI_raise)[0x7f00aa0c7207] :0(__GI_abort)[0x7f00aa0c88f8] /usr/libexec/mysqld(+0x2d73b7)[0x55a6a43af3b7] /usr/libexec/mysqld(+0x6f87d0)[0x55a6a47d07d0] /usr/libexec/mysqld(+0x657ade)[0x55a6a472fade] /usr/libexec/mysqld(+0x671153)[0x55a6a4749153] /usr/libexec/mysqld(+0x666faf)[0x55a6a473efaf] /usr/libexec/mysqld(+0x668d94)[0x55a6a4740d94] /usr/libexec/mysqld(+0x66a6c7)[0x55a6a47426c7] /usr/libexec/mysqld(+0x60a5a0)[0x55a6a46e25a0] /usr/libexec/mysqld(+0x60b54b)[0x55a6a46e354b] /usr/libexec/mysqld(_Z19ha_commit_one_phaseP3THDb+0x80)[0x55a6a457eac0] /usr/libexec/mysqld(_Z15ha_commit_transP3THDb+0x356)[0x55a6a457f236] /usr/libexec/mysqld(_Z17trans_commit_stmtP3THD+0x1b)[0x55a6a45123bb] /usr/libexec/mysqld(_Z21mysql_execute_commandP3THD+0x3dc)[0x55a6a444a9ec] /usr/libexec/mysqld(_Z11mysql_parseP3THDPcjP12Parser_state+0x125)[0x55a6a4451445] /usr/libexec/mysqld(_Z16dispatch_command19enum_server_commandP3THDPcj+0x1750)[0x55a6a44534a0] /usr/libexec/mysqld(_Z24do_handle_one_connectionP3THD+0x1c2)[0x55a6a4505a22] /usr/libexec/mysqld(handle_one_connection+0x4a)[0x55a6a4505aca] pthread_create.c:0(start_thread)[0x7f00ab995dd5] /lib64/libc.so.6(clone+0x6d)[0x7f00aa18eead] Trying to get some variables. Some pointers may be invalid and cause the dump to abort. Query (0x7f0064004c18): UPDATE `ipaddresses` SET `lastSeen`='2019-04-23 23:15:02' WHERE `id`='5956' Connection ID (thread ID): 12 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=on,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=off,table_elimination=on,extended_keys=off 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. 190423 23:15:13 mysqld_safe Number of processes running now: 0 190423 23:15:13 mysqld_safe mysqld restarted 190423 23:15:13 [Note] /usr/libexec/mysqld (mysqld 5.5.60-MariaDB) starting as process 13179 ... 190423 23:15:13 InnoDB: The InnoDB memory heap is disabled 190423 23:15:13 InnoDB: Mutexes and rw_locks use GCC atomic builtins 190423 23:15:13 InnoDB: Compressed tables use zlib 1.2.7 190423 23:15:13 InnoDB: Using Linux native AIO 190423 23:15:13 InnoDB: Initializing buffer pool, size = 128.0M 190423 23:15:13 InnoDB: Completed initialization of buffer pool 190423 23:15:13 InnoDB: highest supported file format is Barracuda. 190423 23:15:13 InnoDB: Starting crash recovery from checkpoint LSN=17741697 InnoDB: Restoring possible half-written data pages from the doublewrite buffer... 190423 23:15:13 InnoDB: Starting final batch to recover 3 pages from redo log 190423 23:15:14 InnoDB: Waiting for the background threads to start 190423 23:15:15 Percona XtraDB (http://www.percona.com) 5.5.59-MariaDB-38.11 started; log sequence number 17774497 190423 23:15:15 [Note] Plugin 'FEEDBACK' is disabled. 190423 23:15:15 [Note] Server socket created on IP: '0.0.0.0'. 190423 23:15:15 [Note] Event Scheduler: Loaded 0 events 190423 23:15:15 [Note] /usr/libexec/mysqld: ready for connections. Version: '5.5.60-MariaDB' socket: '/data/mysql/mysql.sock' port: 3306 MariaDB Server 190423 23:30:14 InnoDB: Assertion failure in thread 140203642164992 in file fut0lst.ic line 83 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: http://dev.mysql.com/doc/refman/5.5/en/forcing-innodb-recovery.html InnoDB: about forcing recovery. 190423 23:30:14 [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 http://kb.askmonty.org/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: 5.5.60-MariaDB key_buffer_size=134217728 read_buffer_size=131072 max_used_connections=3 max_threads=153 thread_count=1 It is possible that mysqld could use up to key_buffer_size + (read_buffer_size + sort_buffer_size)*max_threads = 466718 K bytes of memory Hope that's ok; if not, decrease some variables in the equation. Thread pointer: 0x564315a5cf90 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 = 0x7f83b4498d80 thread_stack 0x48000 /usr/libexec/mysqld(my_print_stacktrace+0x3d)[0x564313000cbd] /usr/libexec/mysqld(handle_fatal_signal+0x515)[0x564312c154a5] sigaction.c:0(__restore_rt)[0x7f83ba2f85d0] :0(__GI_raise)[0x7f83b8a22207] :0(__GI_abort)[0x7f83b8a238f8] /usr/libexec/mysqld(+0x2d73b7)[0x564312a483b7] /usr/libexec/mysqld(+0x6f87d0)[0x564312e697d0] /usr/libexec/mysqld(+0x657ade)[0x564312dc8ade] /usr/libexec/mysqld(+0x671153)[0x564312de2153] /usr/libexec/mysqld(+0x666faf)[0x564312dd7faf] /usr/libexec/mysqld(+0x668d94)[0x564312dd9d94] /usr/libexec/mysqld(+0x66a6c7)[0x564312ddb6c7] /usr/libexec/mysqld(+0x60a5a0)[0x564312d7b5a0] /usr/libexec/mysqld(+0x60b54b)[0x564312d7c54b] /usr/libexec/mysqld(_Z19ha_commit_one_phaseP3THDb+0x80)[0x564312c17ac0] /usr/libexec/mysqld(_Z15ha_commit_transP3THDb+0x356)[0x564312c18236] /usr/libexec/mysqld(_Z17trans_commit_stmtP3THD+0x1b)[0x564312bab3bb] /usr/libexec/mysqld(_Z21mysql_execute_commandP3THD+0x3dc)[0x564312ae39ec] /usr/libexec/mysqld(_Z11mysql_parseP3THDPcjP12Parser_state+0x125)[0x564312aea445] /usr/libexec/mysqld(_Z16dispatch_command19enum_server_commandP3THDPcj+0x1750)[0x564312aec4a0] /usr/libexec/mysqld(_Z24do_handle_one_connectionP3THD+0x1c2)[0x564312b9ea22] /usr/libexec/mysqld(handle_one_connection+0x4a)[0x564312b9eaca] pthread_create.c:0(start_thread)[0x7f83ba2f0dd5] /lib64/libc.so.6(clone+0x6d)[0x7f83b8ae9ead] Trying to get some variables. Some pointers may be invalid and cause the dump to abort. Query (0x7f8374004c18): UPDATE `ipaddresses` SET `lastSeen`='2019-04-23 23:30:01' WHERE `id`='5956' Connection ID (thread ID): 12 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=on,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=off,table_elimination=on,extended_keys=off 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. 190423 23:30:14 mysqld_safe Number of processes running now: 0 190423 23:30:14 mysqld_safe mysqld restarted 190423 23:30:14 [Note] /usr/libexec/mysqld (mysqld 5.5.60-MariaDB) starting as process 15114 ... 190423 23:30:14 InnoDB: The InnoDB memory heap is disabled 190423 23:30:14 InnoDB: Mutexes and rw_locks use GCC atomic builtins 190423 23:30:14 InnoDB: Compressed tables use zlib 1.2.7 190423 23:30:14 InnoDB: Using Linux native AIO 190423 23:30:14 InnoDB: Initializing buffer pool, size = 128.0M 190423 23:30:14 InnoDB: Completed initialization of buffer pool 190423 23:30:14 InnoDB: highest supported file format is Barracuda. 190423 23:30:14 InnoDB: Starting crash recovery from checkpoint LSN=17783709 InnoDB: Restoring possible half-written data pages from the doublewrite buffer... 190423 23:30:14 InnoDB: Starting final batch to recover 3 pages from redo log 190423 23:30:15 InnoDB: Waiting for the background threads to start 190423 23:30:16 Percona XtraDB (http://www.percona.com) 5.5.59-MariaDB-38.11 started; log sequence number 17818758 190423 23:30:16 [Note] Plugin 'FEEDBACK' is disabled. 190423 23:30:16 [Note] Server socket created on IP: '0.0.0.0'. 190423 23:30:16 [Note] Event Scheduler: Loaded 0 events 190423 23:30:16 [Note] /usr/libexec/mysqld: ready for connections. Version: '5.5.60-MariaDB' socket: '/data/mysql/mysql.sock' port: 3306 MariaDB Server 190423 23:45:14 InnoDB: Assertion failure in thread 140550189725440 in file fut0lst.ic line 83 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: http://dev.mysql.com/doc/refman/5.5/en/forcing-innodb-recovery.html InnoDB: about forcing recovery. 190423 23:45:14 [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 http://kb.askmonty.org/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: 5.5.60-MariaDB key_buffer_size=134217728 read_buffer_size=131072 max_used_connections=3 max_threads=153 thread_count=1 It is possible that mysqld could use up to key_buffer_size + (read_buffer_size + sort_buffer_size)*max_threads = 466718 K bytes of memory Hope that's ok; if not, decrease some variables in the equation. Thread pointer: 0x564c127f6cb0 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 = 0x7fd46421ad80 thread_stack 0x48000 /usr/libexec/mysqld(my_print_stacktrace+0x3d)[0x564c0fda8cbd] /usr/libexec/mysqld(handle_fatal_signal+0x515)[0x564c0f9bd4a5] sigaction.c:0(__restore_rt)[0x7fd4686c55d0] :0(__GI_raise)[0x7fd466def207] :0(__GI_abort)[0x7fd466df08f8] /usr/libexec/mysqld(+0x2d73b7)[0x564c0f7f03b7] /usr/libexec/mysqld(+0x6f87d0)[0x564c0fc117d0] /usr/libexec/mysqld(+0x657ade)[0x564c0fb70ade] /usr/libexec/mysqld(+0x671153)[0x564c0fb8a153] /usr/libexec/mysqld(+0x666faf)[0x564c0fb7ffaf] /usr/libexec/mysqld(+0x668d94)[0x564c0fb81d94] /usr/libexec/mysqld(+0x66a6c7)[0x564c0fb836c7] /usr/libexec/mysqld(+0x60a5a0)[0x564c0fb235a0] /usr/libexec/mysqld(+0x60b54b)[0x564c0fb2454b] /usr/libexec/mysqld(_Z19ha_commit_one_phaseP3THDb+0x80)[0x564c0f9bfac0] /usr/libexec/mysqld(_Z15ha_commit_transP3THDb+0x356)[0x564c0f9c0236] /usr/libexec/mysqld(_Z17trans_commit_stmtP3THD+0x1b)[0x564c0f9533bb] /usr/libexec/mysqld(_Z21mysql_execute_commandP3THD+0x3dc)[0x564c0f88b9ec] /usr/libexec/mysqld(_Z11mysql_parseP3THDPcjP12Parser_state+0x125)[0x564c0f892445] /usr/libexec/mysqld(_Z16dispatch_command19enum_server_commandP3THDPcj+0x1750)[0x564c0f8944a0] /usr/libexec/mysqld(_Z24do_handle_one_connectionP3THD+0x1c2)[0x564c0f946a22] /usr/libexec/mysqld(handle_one_connection+0x4a)[0x564c0f946aca] pthread_create.c:0(start_thread)[0x7fd4686bddd5] /lib64/libc.so.6(clone+0x6d)[0x7fd466eb6ead] Trying to get some variables. Some pointers may be invalid and cause the dump to abort. Query (0x7fd420004c18): UPDATE `ipaddresses` SET `lastSeen`='2019-04-23 23:45:01' WHERE `id`='5956' Connection ID (thread ID): 12 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=on,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=off,table_elimination=on,extended_keys=off 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. 190423 23:45:14 mysqld_safe Number of processes running now: 0 190423 23:45:14 mysqld_safe mysqld restarted 190423 23:45:14 [Note] /usr/libexec/mysqld (mysqld 5.5.60-MariaDB) starting as process 16590 ... 190423 23:45:14 InnoDB: The InnoDB memory heap is disabled 190423 23:45:14 InnoDB: Mutexes and rw_locks use GCC atomic builtins 190423 23:45:14 InnoDB: Compressed tables use zlib 1.2.7 190423 23:45:14 InnoDB: Using Linux native AIO 190423 23:45:14 InnoDB: Initializing buffer pool, size = 128.0M 190423 23:45:14 InnoDB: Completed initialization of buffer pool 190423 23:45:14 InnoDB: highest supported file format is Barracuda. 190423 23:45:14 InnoDB: Starting crash recovery from checkpoint LSN=17826417 InnoDB: Restoring possible half-written data pages from the doublewrite buffer... 190423 23:45:14 InnoDB: Starting final batch to recover 3 pages from redo log 190423 23:45:14 InnoDB: Waiting for the background threads to start 190423 23:45:15 Percona XtraDB (http://www.percona.com) 5.5.59-MariaDB-38.11 started; log sequence number 17862135 190423 23:45:15 [Note] Plugin 'FEEDBACK' is disabled. 190423 23:45:15 [Note] Server socket created on IP: '0.0.0.0'. 190423 23:45:15 [Note] Event Scheduler: Loaded 0 events 190423 23:45:15 [Note] /usr/libexec/mysqld: ready for connections. Version: '5.5.60-MariaDB' socket: '/data/mysql/mysql.sock' port: 3306 MariaDB Server 190424 0:00:13 InnoDB: Assertion failure in thread 139955806447360 in file fut0lst.ic line 83 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: http://dev.mysql.com/doc/refman/5.5/en/forcing-innodb-recovery.html InnoDB: about forcing recovery. 190424 0:00:13 [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 http://kb.askmonty.org/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: 5.5.60-MariaDB key_buffer_size=134217728 read_buffer_size=131072 max_used_connections=3 max_threads=153 thread_count=1 It is possible that mysqld could use up to key_buffer_size + (read_buffer_size + sort_buffer_size)*max_threads = 466718 K bytes of memory Hope that's ok; if not, decrease some variables in the equation. Thread pointer: 0x55c5ba6213b0 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 = 0x7f4a00209d80 thread_stack 0x48000 /usr/libexec/mysqld(my_print_stacktrace+0x3d)[0x55c5b7079cbd] /usr/libexec/mysqld(handle_fatal_signal+0x515)[0x55c5b6c8e4a5] sigaction.c:0(__restore_rt)[0x7f4a049115d0] :0(__GI_raise)[0x7f4a0303b207] :0(__GI_abort)[0x7f4a0303c8f8] /usr/libexec/mysqld(+0x2d73b7)[0x55c5b6ac13b7] /usr/libexec/mysqld(+0x6f87d0)[0x55c5b6ee27d0] /usr/libexec/mysqld(+0x657ade)[0x55c5b6e41ade] /usr/libexec/mysqld(+0x671153)[0x55c5b6e5b153] /usr/libexec/mysqld(+0x666faf)[0x55c5b6e50faf] /usr/libexec/mysqld(+0x668d94)[0x55c5b6e52d94] /usr/libexec/mysqld(+0x66a6c7)[0x55c5b6e546c7] /usr/libexec/mysqld(+0x60a5a0)[0x55c5b6df45a0] /usr/libexec/mysqld(+0x60b54b)[0x55c5b6df554b] /usr/libexec/mysqld(_Z19ha_commit_one_phaseP3THDb+0x80)[0x55c5b6c90ac0] /usr/libexec/mysqld(_Z15ha_commit_transP3THDb+0x356)[0x55c5b6c91236] /usr/libexec/mysqld(_Z17trans_commit_stmtP3THD+0x1b)[0x55c5b6c243bb] /usr/libexec/mysqld(_Z21mysql_execute_commandP3THD+0x3dc)[0x55c5b6b5c9ec] /usr/libexec/mysqld(_Z11mysql_parseP3THDPcjP12Parser_state+0x125)[0x55c5b6b63445] /usr/libexec/mysqld(_Z16dispatch_command19enum_server_commandP3THDPcj+0x1750)[0x55c5b6b654a0] /usr/libexec/mysqld(_Z24do_handle_one_connectionP3THD+0x1c2)[0x55c5b6c17a22] /usr/libexec/mysqld(handle_one_connection+0x4a)[0x55c5b6c17aca] pthread_create.c:0(start_thread)[0x7f4a04909dd5] /lib64/libc.so.6(clone+0x6d)[0x7f4a03102ead] Trying to get some variables. Some pointers may be invalid and cause the dump to abort. Query (0x7f49bc004c18): UPDATE `ipaddresses` SET `lastSeen`='2019-04-24 00:00:01' WHERE `id`='5956' Connection ID (thread ID): 12 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=on,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=off,table_elimination=on,extended_keys=off 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. 190424 00:00:13 mysqld_safe Number of processes running now: 0 190424 00:00:13 mysqld_safe mysqld restarted 190424 0:00:13 [Note] /usr/libexec/mysqld (mysqld 5.5.60-MariaDB) starting as process 18556 ... 190424 0:00:13 InnoDB: The InnoDB memory heap is disabled 190424 0:00:13 InnoDB: Mutexes and rw_locks use GCC atomic builtins 190424 0:00:13 InnoDB: Compressed tables use zlib 1.2.7 190424 0:00:13 InnoDB: Using Linux native AIO 190424 0:00:13 InnoDB: Initializing buffer pool, size = 128.0M 190424 0:00:13 InnoDB: Completed initialization of buffer pool 190424 0:00:13 InnoDB: highest supported file format is Barracuda. 190424 0:00:13 InnoDB: Starting crash recovery from checkpoint LSN=17868492 InnoDB: Restoring possible half-written data pages from the doublewrite buffer... 190424 0:00:13 InnoDB: Starting final batch to recover 3 pages from redo log 190424 0:00:14 InnoDB: Waiting for the background threads to start 190424 0:00:15 Percona XtraDB (http://www.percona.com) 5.5.59-MariaDB-38.11 started; log sequence number 17902008 190424 0:00:15 [Note] Plugin 'FEEDBACK' is disabled. 190424 0:00:15 [Note] Server socket created on IP: '0.0.0.0'. 190424 0:00:15 [Note] Event Scheduler: Loaded 0 events 190424 0:00:15 [Note] /usr/libexec/mysqld: ready for connections. Version: '5.5.60-MariaDB' socket: '/data/mysql/mysql.sock' port: 3306 MariaDB Server 190424 0:15:14 InnoDB: Assertion failure in thread 139924801906432 in file fut0lst.ic line 83 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: http://dev.mysql.com/doc/refman/5.5/en/forcing-innodb-recovery.html InnoDB: about forcing recovery. 190424 0:15:14 [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 http://kb.askmonty.org/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: 5.5.60-MariaDB key_buffer_size=134217728 read_buffer_size=131072 max_used_connections=3 max_threads=153 thread_count=1 It is possible that mysqld could use up to key_buffer_size + (read_buffer_size + sort_buffer_size)*max_threads = 466718 K bytes of memory Hope that's ok; if not, decrease some variables in the equation. Thread pointer: 0x55ea597781f0 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 = 0x7f42c81cdd80 thread_stack 0x48000 /usr/libexec/mysqld(my_print_stacktrace+0x3d)[0x55ea56ad5cbd] /usr/libexec/mysqld(handle_fatal_signal+0x515)[0x55ea566ea4a5] sigaction.c:0(__restore_rt)[0x7f42cde1a5d0] :0(__GI_raise)[0x7f42cc544207] :0(__GI_abort)[0x7f42cc5458f8] /usr/libexec/mysqld(+0x2d73b7)[0x55ea5651d3b7] /usr/libexec/mysqld(+0x6f87d0)[0x55ea5693e7d0] /usr/libexec/mysqld(+0x657ade)[0x55ea5689dade] /usr/libexec/mysqld(+0x671153)[0x55ea568b7153] /usr/libexec/mysqld(+0x666faf)[0x55ea568acfaf] /usr/libexec/mysqld(+0x668d94)[0x55ea568aed94] /usr/libexec/mysqld(+0x66a6c7)[0x55ea568b06c7] /usr/libexec/mysqld(+0x60a5a0)[0x55ea568505a0] /usr/libexec/mysqld(+0x60b54b)[0x55ea5685154b] /usr/libexec/mysqld(_Z19ha_commit_one_phaseP3THDb+0x80)[0x55ea566ecac0] /usr/libexec/mysqld(_Z15ha_commit_transP3THDb+0x356)[0x55ea566ed236] /usr/libexec/mysqld(_Z17trans_commit_stmtP3THD+0x1b)[0x55ea566803bb] /usr/libexec/mysqld(_Z21mysql_execute_commandP3THD+0x3dc)[0x55ea565b89ec] /usr/libexec/mysqld(_Z11mysql_parseP3THDPcjP12Parser_state+0x125)[0x55ea565bf445] /usr/libexec/mysqld(_Z16dispatch_command19enum_server_commandP3THDPcj+0x1750)[0x55ea565c14a0] /usr/libexec/mysqld(_Z24do_handle_one_connectionP3THD+0x1c2)[0x55ea56673a22] /usr/libexec/mysqld(handle_one_connection+0x4a)[0x55ea56673aca] pthread_create.c:0(start_thread)[0x7f42cde12dd5] /lib64/libc.so.6(clone+0x6d)[0x7f42cc60bead] Trying to get some variables. Some pointers may be invalid and cause the dump to abort. Query (0x7f4288004c18): UPDATE `ipaddresses` SET `lastSeen`='2019-04-24 00:15:01' WHERE `id`='5956' Connection ID (thread ID): 12 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=on,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=off,table_elimination=on,extended_keys=off 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. 190424 00:15:14 mysqld_safe Number of processes running now: 0 190424 00:15:14 mysqld_safe mysqld restarted 190424 0:15:14 [Note] /usr/libexec/mysqld (mysqld 5.5.60-MariaDB) starting as process 20044 ... 190424 0:15:14 InnoDB: The InnoDB memory heap is disabled 190424 0:15:14 InnoDB: Mutexes and rw_locks use GCC atomic builtins 190424 0:15:14 InnoDB: Compressed tables use zlib 1.2.7 190424 0:15:14 InnoDB: Using Linux native AIO 190424 0:15:14 InnoDB: Initializing buffer pool, size = 128.0M 190424 0:15:14 InnoDB: Completed initialization of buffer pool 190424 0:15:14 InnoDB: highest supported file format is Barracuda. 190424 0:15:14 InnoDB: Starting crash recovery from checkpoint LSN=17908466 InnoDB: Restoring possible half-written data pages from the doublewrite buffer... 190424 0:15:14 InnoDB: Starting final batch to recover 3 pages from redo log 190424 0:15:14 InnoDB: Waiting for the background threads to start 190424 0:15:15 Percona XtraDB (http://www.percona.com) 5.5.59-MariaDB-38.11 started; log sequence number 17942822 190424 0:15:15 [Note] Plugin 'FEEDBACK' is disabled. 190424 0:15:15 [Note] Server socket created on IP: '0.0.0.0'. 190424 0:15:15 [Note] Event Scheduler: Loaded 0 events 190424 0:15:15 [Note] /usr/libexec/mysqld: ready for connections. Version: '5.5.60-MariaDB' socket: '/data/mysql/mysql.sock' port: 3306 MariaDB Server 190424 0:30:12 InnoDB: Assertion failure in thread 140376579610368 in file fut0lst.ic line 83 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: http://dev.mysql.com/doc/refman/5.5/en/forcing-innodb-recovery.html InnoDB: about forcing recovery. 190424 0:30:12 [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 http://kb.askmonty.org/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: 5.5.60-MariaDB key_buffer_size=134217728 read_buffer_size=131072 max_used_connections=3 max_threads=153 thread_count=1 It is possible that mysqld could use up to key_buffer_size + (read_buffer_size + sort_buffer_size)*max_threads = 466718 K bytes of memory Hope that's ok; if not, decrease some variables in the equation. Thread pointer: 0x5612e4b9a3b0 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 = 0x7fabf8298d80 thread_stack 0x48000 /usr/libexec/mysqld(my_print_stacktrace+0x3d)[0x5612e19aecbd] /usr/libexec/mysqld(handle_fatal_signal+0x515)[0x5612e15c34a5] sigaction.c:0(__restore_rt)[0x7fabfcf445d0] :0(__GI_raise)[0x7fabfb66e207] :0(__GI_abort)[0x7fabfb66f8f8] /usr/libexec/mysqld(+0x2d73b7)[0x5612e13f63b7] /usr/libexec/mysqld(+0x6f87d0)[0x5612e18177d0] /usr/libexec/mysqld(+0x657ade)[0x5612e1776ade] /usr/libexec/mysqld(+0x671153)[0x5612e1790153] /usr/libexec/mysqld(+0x666faf)[0x5612e1785faf] /usr/libexec/mysqld(+0x668d94)[0x5612e1787d94] /usr/libexec/mysqld(+0x66a6c7)[0x5612e17896c7] /usr/libexec/mysqld(+0x60a5a0)[0x5612e17295a0] /usr/libexec/mysqld(+0x60b54b)[0x5612e172a54b] /usr/libexec/mysqld(_Z19ha_commit_one_phaseP3THDb+0x80)[0x5612e15c5ac0] /usr/libexec/mysqld(_Z15ha_commit_transP3THDb+0x356)[0x5612e15c6236] /usr/libexec/mysqld(_Z17trans_commit_stmtP3THD+0x1b)[0x5612e15593bb] /usr/libexec/mysqld(_Z21mysql_execute_commandP3THD+0x3dc)[0x5612e14919ec] /usr/libexec/mysqld(_Z11mysql_parseP3THDPcjP12Parser_state+0x125)[0x5612e1498445] /usr/libexec/mysqld(_Z16dispatch_command19enum_server_commandP3THDPcj+0x1750)[0x5612e149a4a0] /usr/libexec/mysqld(_Z24do_handle_one_connectionP3THD+0x1c2)[0x5612e154ca22] /usr/libexec/mysqld(handle_one_connection+0x4a)[0x5612e154caca] pthread_create.c:0(start_thread)[0x7fabfcf3cdd5] /lib64/libc.so.6(clone+0x6d)[0x7fabfb735ead] Trying to get some variables. Some pointers may be invalid and cause the dump to abort. Query (0x7fabbc004c18): UPDATE `ipaddresses` SET `lastSeen`='2019-04-24 00:30:01' WHERE `id`='5956' Connection ID (thread ID): 12 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=on,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=off,table_elimination=on,extended_keys=off 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. 190424 00:30:13 mysqld_safe Number of processes running now: 0 190424 00:30:13 mysqld_safe mysqld restarted 190424 0:30:13 [Note] /usr/libexec/mysqld (mysqld 5.5.60-MariaDB) starting as process 21989 ... 190424 0:30:13 InnoDB: The InnoDB memory heap is disabled 190424 0:30:13 InnoDB: Mutexes and rw_locks use GCC atomic builtins 190424 0:30:13 InnoDB: Compressed tables use zlib 1.2.7 190424 0:30:13 InnoDB: Using Linux native AIO 190424 0:30:13 InnoDB: Initializing buffer pool, size = 128.0M 190424 0:30:13 InnoDB: Completed initialization of buffer pool 190424 0:30:13 InnoDB: highest supported file format is Barracuda. 190424 0:30:13 InnoDB: Starting crash recovery from checkpoint LSN=17949158 InnoDB: Restoring possible half-written data pages from the doublewrite buffer... 190424 0:30:13 InnoDB: Starting final batch to recover 3 pages from redo log 190424 0:30:13 InnoDB: Waiting for the background threads to start 190424 0:30:14 Percona XtraDB (http://www.percona.com) 5.5.59-MariaDB-38.11 started; log sequence number 17982820 190424 0:30:14 [Note] Plugin 'FEEDBACK' is disabled. 190424 0:30:14 [Note] Server socket created on IP: '0.0.0.0'. 190424 0:30:14 [Note] Event Scheduler: Loaded 0 events 190424 0:30:14 [Note] /usr/libexec/mysqld: ready for connections. Version: '5.5.60-MariaDB' socket: '/data/mysql/mysql.sock' port: 3306 MariaDB Server 190424 0:45:13 InnoDB: Assertion failure in thread 139919299749632 in file fut0lst.ic line 83 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: http://dev.mysql.com/doc/refman/5.5/en/forcing-innodb-recovery.html InnoDB: about forcing recovery. 190424 0:45:13 [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 http://kb.askmonty.org/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: 5.5.60-MariaDB key_buffer_size=134217728 read_buffer_size=131072 max_used_connections=3 max_threads=153 thread_count=1 It is possible that mysqld could use up to key_buffer_size + (read_buffer_size + sort_buffer_size)*max_threads = 466718 K bytes of memory Hope that's ok; if not, decrease some variables in the equation. Thread pointer: 0x55b2e747a030 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 = 0x7f4180289d80 thread_stack 0x48000 /usr/libexec/mysqld(my_print_stacktrace+0x3d)[0x55b2e3b0fcbd] /usr/libexec/mysqld(handle_fatal_signal+0x515)[0x55b2e37244a5] sigaction.c:0(__restore_rt)[0x7f4185ed65d0] :0(__GI_raise)[0x7f4184600207] :0(__GI_abort)[0x7f41846018f8] /usr/libexec/mysqld(+0x2d73b7)[0x55b2e35573b7] /usr/libexec/mysqld(+0x6f87d0)[0x55b2e39787d0] /usr/libexec/mysqld(+0x657ade)[0x55b2e38d7ade] /usr/libexec/mysqld(+0x671153)[0x55b2e38f1153] /usr/libexec/mysqld(+0x666faf)[0x55b2e38e6faf] /usr/libexec/mysqld(+0x668d94)[0x55b2e38e8d94] /usr/libexec/mysqld(+0x66a6c7)[0x55b2e38ea6c7] /usr/libexec/mysqld(+0x60a5a0)[0x55b2e388a5a0] /usr/libexec/mysqld(+0x60b54b)[0x55b2e388b54b] /usr/libexec/mysqld(_Z19ha_commit_one_phaseP3THDb+0x80)[0x55b2e3726ac0] /usr/libexec/mysqld(_Z15ha_commit_transP3THDb+0x356)[0x55b2e3727236] /usr/libexec/mysqld(_Z17trans_commit_stmtP3THD+0x1b)[0x55b2e36ba3bb] /usr/libexec/mysqld(_Z21mysql_execute_commandP3THD+0x3dc)[0x55b2e35f29ec] /usr/libexec/mysqld(_Z11mysql_parseP3THDPcjP12Parser_state+0x125)[0x55b2e35f9445] /usr/libexec/mysqld(_Z16dispatch_command19enum_server_commandP3THDPcj+0x1750)[0x55b2e35fb4a0] /usr/libexec/mysqld(_Z24do_handle_one_connectionP3THD+0x1c2)[0x55b2e36ada22] /usr/libexec/mysqld(handle_one_connection+0x4a)[0x55b2e36adaca] pthread_create.c:0(start_thread)[0x7f4185ecedd5] /lib64/libc.so.6(clone+0x6d)[0x7f41846c7ead] Trying to get some variables. Some pointers may be invalid and cause the dump to abort. Query (0x7f4140004c18): UPDATE `ipaddresses` SET `lastSeen`='2019-04-24 00:45:01' WHERE `id`='5956' Connection ID (thread ID): 12 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=on,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=off,table_elimination=on,extended_keys=off 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. 190424 00:45:13 mysqld_safe Number of processes running now: 0 190424 00:45:13 mysqld_safe mysqld restarted 190424 0:45:13 [Note] /usr/libexec/mysqld (mysqld 5.5.60-MariaDB) starting as process 23463 ... 190424 0:45:13 InnoDB: The InnoDB memory heap is disabled 190424 0:45:13 InnoDB: Mutexes and rw_locks use GCC atomic builtins 190424 0:45:13 InnoDB: Compressed tables use zlib 1.2.7 190424 0:45:13 InnoDB: Using Linux native AIO 190424 0:45:13 InnoDB: Initializing buffer pool, size = 128.0M 190424 0:45:13 InnoDB: Completed initialization of buffer pool 190424 0:45:13 InnoDB: highest supported file format is Barracuda. 190424 0:45:13 InnoDB: Starting crash recovery from checkpoint LSN=17989606 InnoDB: Restoring possible half-written data pages from the doublewrite buffer... 190424 0:45:13 InnoDB: Starting final batch to recover 3 pages from redo log 190424 0:45:14 InnoDB: Waiting for the background threads to start 190424 0:45:15 Percona XtraDB (http://www.percona.com) 5.5.59-MariaDB-38.11 started; log sequence number 18024663 190424 0:45:15 [Note] Plugin 'FEEDBACK' is disabled. 190424 0:45:15 [Note] Server socket created on IP: '0.0.0.0'. 190424 0:45:15 [Note] Event Scheduler: Loaded 0 events 190424 0:45:15 [Note] /usr/libexec/mysqld: ready for connections. Version: '5.5.60-MariaDB' socket: '/data/mysql/mysql.sock' port: 3306 MariaDB Server 190424 1:00:13 InnoDB: Assertion failure in thread 139648355759872 in file fut0lst.ic line 83 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: http://dev.mysql.com/doc/refman/5.5/en/forcing-innodb-recovery.html InnoDB: about forcing recovery. 190424 1:00:13 [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 http://kb.askmonty.org/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: 5.5.60-MariaDB key_buffer_size=134217728 read_buffer_size=131072 max_used_connections=3 max_threads=153 thread_count=1 It is possible that mysqld could use up to key_buffer_size + (read_buffer_size + sort_buffer_size)*max_threads = 466718 K bytes of memory Hope that's ok; if not, decrease some variables in the equation. Thread pointer: 0x556ae4a9ae70 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 = 0x7f026aa36d80 thread_stack 0x48000 /usr/libexec/mysqld(my_print_stacktrace+0x3d)[0x556ae206acbd] /usr/libexec/mysqld(handle_fatal_signal+0x515)[0x556ae1c7f4a5] sigaction.c:0(__restore_rt)[0x7f0287ca05d0] :0(__GI_raise)[0x7f02863ca207] :0(__GI_abort)[0x7f02863cb8f8] /usr/libexec/mysqld(+0x2d73b7)[0x556ae1ab23b7] /usr/libexec/mysqld(+0x6f87d0)[0x556ae1ed37d0] /usr/libexec/mysqld(+0x657ade)[0x556ae1e32ade] /usr/libexec/mysqld(+0x671153)[0x556ae1e4c153] /usr/libexec/mysqld(+0x666faf)[0x556ae1e41faf] /usr/libexec/mysqld(+0x668d94)[0x556ae1e43d94] /usr/libexec/mysqld(+0x66a6c7)[0x556ae1e456c7] /usr/libexec/mysqld(+0x60a5a0)[0x556ae1de55a0] /usr/libexec/mysqld(+0x60b54b)[0x556ae1de654b] /usr/libexec/mysqld(_Z19ha_commit_one_phaseP3THDb+0x80)[0x556ae1c81ac0] /usr/libexec/mysqld(_Z15ha_commit_transP3THDb+0x356)[0x556ae1c82236] /usr/libexec/mysqld(_Z17trans_commit_stmtP3THD+0x1b)[0x556ae1c153bb] /usr/libexec/mysqld(_Z21mysql_execute_commandP3THD+0x3dc)[0x556ae1b4d9ec] /usr/libexec/mysqld(_Z11mysql_parseP3THDPcjP12Parser_state+0x125)[0x556ae1b54445] /usr/libexec/mysqld(_Z16dispatch_command19enum_server_commandP3THDPcj+0x1750)[0x556ae1b564a0] /usr/libexec/mysqld(_Z24do_handle_one_connectionP3THD+0x1c2)[0x556ae1c08a22] /usr/libexec/mysqld(handle_one_connection+0x4a)[0x556ae1c08aca] pthread_create.c:0(start_thread)[0x7f0287c98dd5] /lib64/libc.so.6(clone+0x6d)[0x7f0286491ead] Trying to get some variables. Some pointers may be invalid and cause the dump to abort. Query (0x7f0240004c18): UPDATE `ipaddresses` SET `lastSeen`='2019-04-24 01:00:01' WHERE `id`='5956' Connection ID (thread ID): 12 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=on,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=off,table_elimination=on,extended_keys=off 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. 190424 01:00:13 mysqld_safe Number of processes running now: 0 190424 01:00:13 mysqld_safe mysqld restarted 190424 1:00:14 [Note] /usr/libexec/mysqld (mysqld 5.5.60-MariaDB) starting as process 25416 ... 190424 1:00:14 InnoDB: The InnoDB memory heap is disabled 190424 1:00:14 InnoDB: Mutexes and rw_locks use GCC atomic builtins 190424 1:00:14 InnoDB: Compressed tables use zlib 1.2.7 190424 1:00:14 InnoDB: Using Linux native AIO 190424 1:00:14 InnoDB: Initializing buffer pool, size = 128.0M 190424 1:00:14 InnoDB: Completed initialization of buffer pool 190424 1:00:14 InnoDB: highest supported file format is Barracuda. 190424 1:00:14 InnoDB: Starting crash recovery from checkpoint LSN=18032200 InnoDB: Restoring possible half-written data pages from the doublewrite buffer... 190424 1:00:14 InnoDB: Starting final batch to recover 3 pages from redo log 190424 1:00:14 InnoDB: Waiting for the background threads to start 190424 1:00:15 Percona XtraDB (http://www.percona.com) 5.5.59-MariaDB-38.11 started; log sequence number 18067202 190424 1:00:15 [Note] Plugin 'FEEDBACK' is disabled. 190424 1:00:15 [Note] Server socket created on IP: '0.0.0.0'. 190424 1:00:15 [Note] Event Scheduler: Loaded 0 events 190424 1:00:15 [Note] /usr/libexec/mysqld: ready for connections. Version: '5.5.60-MariaDB' socket: '/data/mysql/mysql.sock' port: 3306 MariaDB Server 190424 1:15:13 InnoDB: Assertion failure in thread 140481109350144 in file fut0lst.ic line 83 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: http://dev.mysql.com/doc/refman/5.5/en/forcing-innodb-recovery.html InnoDB: about forcing recovery. 190424 1:15:13 [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 http://kb.askmonty.org/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: 5.5.60-MariaDB key_buffer_size=134217728 read_buffer_size=131072 max_used_connections=3 max_threads=153 thread_count=1 It is possible that mysqld could use up to key_buffer_size + (read_buffer_size + sort_buffer_size)*max_threads = 466718 K bytes of memory Hope that's ok; if not, decrease some variables in the equation. Thread pointer: 0x561f6c5111f0 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 = 0x7fc44e9ecd80 thread_stack 0x48000 /usr/libexec/mysqld(my_print_stacktrace+0x3d)[0x561f6a8e6cbd] /usr/libexec/mysqld(handle_fatal_signal+0x515)[0x561f6a4fb4a5] sigaction.c:0(__restore_rt)[0x7fc46bcc55d0] :0(__GI_raise)[0x7fc46a3ef207] :0(__GI_abort)[0x7fc46a3f08f8] /usr/libexec/mysqld(+0x2d73b7)[0x561f6a32e3b7] /usr/libexec/mysqld(+0x6f87d0)[0x561f6a74f7d0] /usr/libexec/mysqld(+0x657ade)[0x561f6a6aeade] /usr/libexec/mysqld(+0x671153)[0x561f6a6c8153] /usr/libexec/mysqld(+0x666faf)[0x561f6a6bdfaf] /usr/libexec/mysqld(+0x668d94)[0x561f6a6bfd94] /usr/libexec/mysqld(+0x66a6c7)[0x561f6a6c16c7] /usr/libexec/mysqld(+0x60a5a0)[0x561f6a6615a0] /usr/libexec/mysqld(+0x60b54b)[0x561f6a66254b] /usr/libexec/mysqld(_Z19ha_commit_one_phaseP3THDb+0x80)[0x561f6a4fdac0] /usr/libexec/mysqld(_Z15ha_commit_transP3THDb+0x356)[0x561f6a4fe236] /usr/libexec/mysqld(_Z17trans_commit_stmtP3THD+0x1b)[0x561f6a4913bb] /usr/libexec/mysqld(_Z21mysql_execute_commandP3THD+0x3dc)[0x561f6a3c99ec] /usr/libexec/mysqld(_Z11mysql_parseP3THDPcjP12Parser_state+0x125)[0x561f6a3d0445] /usr/libexec/mysqld(_Z16dispatch_command19enum_server_commandP3THDPcj+0x1750)[0x561f6a3d24a0] /usr/libexec/mysqld(_Z24do_handle_one_connectionP3THD+0x1c2)[0x561f6a484a22] /usr/libexec/mysqld(handle_one_connection+0x4a)[0x561f6a484aca] pthread_create.c:0(start_thread)[0x7fc46bcbddd5] /lib64/libc.so.6(clone+0x6d)[0x7fc46a4b6ead] Trying to get some variables. Some pointers may be invalid and cause the dump to abort. Query (0x7fc424004c18): UPDATE `ipaddresses` SET `lastSeen`='2019-04-24 01:15:02' WHERE `id`='5956' Connection ID (thread ID): 12 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=on,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=off,table_elimination=on,extended_keys=off 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. 190424 01:15:14 mysqld_safe Number of processes running now: 0 190424 01:15:14 mysqld_safe mysqld restarted 190424 1:15:14 [Note] /usr/libexec/mysqld (mysqld 5.5.60-MariaDB) starting as process 26910 ... 190424 1:15:14 InnoDB: The InnoDB memory heap is disabled 190424 1:15:14 InnoDB: Mutexes and rw_locks use GCC atomic builtins 190424 1:15:14 InnoDB: Compressed tables use zlib 1.2.7 190424 1:15:14 InnoDB: Using Linux native AIO 190424 1:15:14 InnoDB: Initializing buffer pool, size = 128.0M 190424 1:15:14 InnoDB: Completed initialization of buffer pool 190424 1:15:14 InnoDB: highest supported file format is Barracuda. 190424 1:15:14 InnoDB: Starting crash recovery from checkpoint LSN=18073666 InnoDB: Restoring possible half-written data pages from the doublewrite buffer... 190424 1:15:14 InnoDB: Starting final batch to recover 3 pages from redo log 190424 1:15:14 InnoDB: Waiting for the background threads to start 190424 1:15:15 Percona XtraDB (http://www.percona.com) 5.5.59-MariaDB-38.11 started; log sequence number 18108058 190424 1:15:15 [Note] Plugin 'FEEDBACK' is disabled. 190424 1:15:15 [Note] Server socket created on IP: '0.0.0.0'. 190424 1:15:15 [Note] Event Scheduler: Loaded 0 events 190424 1:15:15 [Note] /usr/libexec/mysqld: ready for connections. Version: '5.5.60-MariaDB' socket: '/data/mysql/mysql.sock' port: 3306 MariaDB Server 190424 1:30:12 InnoDB: Assertion failure in thread 140086468515584 in file fut0lst.ic line 83 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: http://dev.mysql.com/doc/refman/5.5/en/forcing-innodb-recovery.html InnoDB: about forcing recovery. 190424 1:30:12 [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 http://kb.askmonty.org/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: 5.5.60-MariaDB key_buffer_size=134217728 read_buffer_size=131072 max_used_connections=3 max_threads=153 thread_count=1 It is possible that mysqld could use up to key_buffer_size + (read_buffer_size + sort_buffer_size)*max_threads = 466718 K bytes of memory Hope that's ok; if not, decrease some variables in the equation. Thread pointer: 0x55b0a65c35b0 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 = 0x7f686c318d80 thread_stack 0x48000 /usr/libexec/mysqld(my_print_stacktrace+0x3d)[0x55b0a4883cbd] /usr/libexec/mysqld(handle_fatal_signal+0x515)[0x55b0a44984a5] sigaction.c:0(__restore_rt)[0x7f6872f675d0] :0(__GI_raise)[0x7f6871691207] :0(__GI_abort)[0x7f68716928f8] /usr/libexec/mysqld(+0x2d73b7)[0x55b0a42cb3b7] /usr/libexec/mysqld(+0x6f87d0)[0x55b0a46ec7d0] /usr/libexec/mysqld(+0x657ade)[0x55b0a464bade] /usr/libexec/mysqld(+0x671153)[0x55b0a4665153] /usr/libexec/mysqld(+0x666faf)[0x55b0a465afaf] /usr/libexec/mysqld(+0x668d94)[0x55b0a465cd94] /usr/libexec/mysqld(+0x66a6c7)[0x55b0a465e6c7] /usr/libexec/mysqld(+0x60a5a0)[0x55b0a45fe5a0] /usr/libexec/mysqld(+0x60b54b)[0x55b0a45ff54b] /usr/libexec/mysqld(_Z19ha_commit_one_phaseP3THDb+0x80)[0x55b0a449aac0] /usr/libexec/mysqld(_Z15ha_commit_transP3THDb+0x356)[0x55b0a449b236] /usr/libexec/mysqld(_Z17trans_commit_stmtP3THD+0x1b)[0x55b0a442e3bb] /usr/libexec/mysqld(_Z21mysql_execute_commandP3THD+0x3dc)[0x55b0a43669ec] /usr/libexec/mysqld(_Z11mysql_parseP3THDPcjP12Parser_state+0x125)[0x55b0a436d445] /usr/libexec/mysqld(_Z16dispatch_command19enum_server_commandP3THDPcj+0x1750)[0x55b0a436f4a0] /usr/libexec/mysqld(_Z24do_handle_one_connectionP3THD+0x1c2)[0x55b0a4421a22] /usr/libexec/mysqld(handle_one_connection+0x4a)[0x55b0a4421aca] pthread_create.c:0(start_thread)[0x7f6872f5fdd5] /lib64/libc.so.6(clone+0x6d)[0x7f6871758ead] Trying to get some variables. Some pointers may be invalid and cause the dump to abort. Query (0x7f682c004c18): UPDATE `ipaddresses` SET `lastSeen`='2019-04-24 01:30:01' WHERE `id`='5956' Connection ID (thread ID): 12 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=on,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=off,table_elimination=on,extended_keys=off 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. 190424 01:30:13 mysqld_safe Number of processes running now: 0 190424 01:30:13 mysqld_safe mysqld restarted 190424 1:30:13 [Note] /usr/libexec/mysqld (mysqld 5.5.60-MariaDB) starting as process 28862 ... 190424 1:30:13 InnoDB: The InnoDB memory heap is disabled 190424 1:30:13 InnoDB: Mutexes and rw_locks use GCC atomic builtins 190424 1:30:13 InnoDB: Compressed tables use zlib 1.2.7 190424 1:30:13 InnoDB: Using Linux native AIO 190424 1:30:13 InnoDB: Initializing buffer pool, size = 128.0M 190424 1:30:13 InnoDB: Completed initialization of buffer pool 190424 1:30:13 InnoDB: highest supported file format is Barracuda. 190424 1:30:13 InnoDB: Starting crash recovery from checkpoint LSN=18115322 InnoDB: Restoring possible half-written data pages from the doublewrite buffer... 190424 1:30:13 InnoDB: Starting final batch to recover 3 pages from redo log 190424 1:30:13 InnoDB: Waiting for the background threads to start 190424 1:30:14 Percona XtraDB (http://www.percona.com) 5.5.59-MariaDB-38.11 started; log sequence number 18154868 190424 1:30:14 [Note] Plugin 'FEEDBACK' is disabled. 190424 1:30:14 [Note] Server socket created on IP: '0.0.0.0'. 190424 1:30:14 [Note] Event Scheduler: Loaded 0 events 190424 1:30:14 [Note] /usr/libexec/mysqld: ready for connections. Version: '5.5.60-MariaDB' socket: '/data/mysql/mysql.sock' port: 3306 MariaDB Server 190424 1:45:12 InnoDB: Assertion failure in thread 140123886651136 in file fut0lst.ic line 83 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: http://dev.mysql.com/doc/refman/5.5/en/forcing-innodb-recovery.html InnoDB: about forcing recovery. 190424 1:45:12 [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 http://kb.askmonty.org/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: 5.5.60-MariaDB key_buffer_size=134217728 read_buffer_size=131072 max_used_connections=3 max_threads=153 thread_count=1 It is possible that mysqld could use up to key_buffer_size + (read_buffer_size + sort_buffer_size)*max_threads = 466718 K bytes of memory Hope that's ok; if not, decrease some variables in the equation. Thread pointer: 0x564b2627c3b0 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 = 0x7f71227cfd80 thread_stack 0x48000 /usr/libexec/mysqld(my_print_stacktrace+0x3d)[0x564b24519cbd] /usr/libexec/mysqld(handle_fatal_signal+0x515)[0x564b2412e4a5] sigaction.c:0(__restore_rt)[0x7f713fa915d0] :0(__GI_raise)[0x7f713e1bb207] :0(__GI_abort)[0x7f713e1bc8f8] /usr/libexec/mysqld(+0x2d73b7)[0x564b23f613b7] /usr/libexec/mysqld(+0x6f87d0)[0x564b243827d0] /usr/libexec/mysqld(+0x657ade)[0x564b242e1ade] /usr/libexec/mysqld(+0x671153)[0x564b242fb153] /usr/libexec/mysqld(+0x666faf)[0x564b242f0faf] /usr/libexec/mysqld(+0x668d94)[0x564b242f2d94] /usr/libexec/mysqld(+0x66a6c7)[0x564b242f46c7] /usr/libexec/mysqld(+0x60a5a0)[0x564b242945a0] /usr/libexec/mysqld(+0x60b54b)[0x564b2429554b] /usr/libexec/mysqld(_Z19ha_commit_one_phaseP3THDb+0x80)[0x564b24130ac0] /usr/libexec/mysqld(_Z15ha_commit_transP3THDb+0x356)[0x564b24131236] /usr/libexec/mysqld(_Z17trans_commit_stmtP3THD+0x1b)[0x564b240c43bb] /usr/libexec/mysqld(_Z21mysql_execute_commandP3THD+0x3dc)[0x564b23ffc9ec] /usr/libexec/mysqld(_Z11mysql_parseP3THDPcjP12Parser_state+0x125)[0x564b24003445] /usr/libexec/mysqld(_Z16dispatch_command19enum_server_commandP3THDPcj+0x1750)[0x564b240054a0] /usr/libexec/mysqld(_Z24do_handle_one_connectionP3THD+0x1c2)[0x564b240b7a22] /usr/libexec/mysqld(handle_one_connection+0x4a)[0x564b240b7aca] pthread_create.c:0(start_thread)[0x7f713fa89dd5] /lib64/libc.so.6(clone+0x6d)[0x7f713e282ead] Trying to get some variables. Some pointers may be invalid and cause the dump to abort. Query (0x7f70f8004c18): UPDATE `ipaddresses` SET `lastSeen`='2019-04-24 01:45:01' WHERE `id`='5956' Connection ID (thread ID): 12 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=on,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=off,table_elimination=on,extended_keys=off 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. 190424 01:45:13 mysqld_safe Number of processes running now: 0 190424 01:45:13 mysqld_safe mysqld restarted 190424 1:45:13 [Note] /usr/libexec/mysqld (mysqld 5.5.60-MariaDB) starting as process 30397 ... 190424 1:45:13 InnoDB: The InnoDB memory heap is disabled 190424 1:45:13 InnoDB: Mutexes and rw_locks use GCC atomic builtins 190424 1:45:13 InnoDB: Compressed tables use zlib 1.2.7 190424 1:45:13 InnoDB: Using Linux native AIO 190424 1:45:13 InnoDB: Initializing buffer pool, size = 128.0M 190424 1:45:13 InnoDB: Completed initialization of buffer pool 190424 1:45:13 InnoDB: highest supported file format is Barracuda. 190424 1:45:13 InnoDB: Starting crash recovery from checkpoint LSN=18161450 InnoDB: Restoring possible half-written data pages from the doublewrite buffer... 190424 1:45:13 InnoDB: Starting final batch to recover 5 pages from redo log 190424 1:45:13 InnoDB: Waiting for the background threads to start 190424 1:45:14 Percona XtraDB (http://www.percona.com) 5.5.59-MariaDB-38.11 started; log sequence number 18195905 190424 1:45:14 [Note] Plugin 'FEEDBACK' is disabled. 190424 1:45:14 [Note] Server socket created on IP: '0.0.0.0'. 190424 1:45:14 [Note] Event Scheduler: Loaded 0 events 190424 1:45:14 [Note] /usr/libexec/mysqld: ready for connections. Version: '5.5.60-MariaDB' socket: '/data/mysql/mysql.sock' port: 3306 MariaDB Server 190424 2:00:13 InnoDB: Assertion failure in thread 140502744581888 in file fut0lst.ic line 83 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: http://dev.mysql.com/doc/refman/5.5/en/forcing-innodb-recovery.html InnoDB: about forcing recovery. 190424 2:00:13 [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 http://kb.askmonty.org/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: 5.5.60-MariaDB key_buffer_size=134217728 read_buffer_size=131072 max_used_connections=3 max_threads=153 thread_count=1 It is possible that mysqld could use up to key_buffer_size + (read_buffer_size + sort_buffer_size)*max_threads = 466718 K bytes of memory Hope that's ok; if not, decrease some variables in the equation. Thread pointer: 0x5583f2df3930 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 = 0x7fc9582e3d80 thread_stack 0x48000 /usr/libexec/mysqld(my_print_stacktrace+0x3d)[0x5583efe00cbd] /usr/libexec/mysqld(handle_fatal_signal+0x515)[0x5583efa154a5] sigaction.c:0(__restore_rt)[0x7fc95c7d85d0] :0(__GI_raise)[0x7fc95af02207] :0(__GI_abort)[0x7fc95af038f8] /usr/libexec/mysqld(+0x2d73b7)[0x5583ef8483b7] /usr/libexec/mysqld(+0x6f87d0)[0x5583efc697d0] /usr/libexec/mysqld(+0x657ade)[0x5583efbc8ade] /usr/libexec/mysqld(+0x671153)[0x5583efbe2153] /usr/libexec/mysqld(+0x666faf)[0x5583efbd7faf] /usr/libexec/mysqld(+0x668d94)[0x5583efbd9d94] /usr/libexec/mysqld(+0x66a6c7)[0x5583efbdb6c7] /usr/libexec/mysqld(+0x60a5a0)[0x5583efb7b5a0] /usr/libexec/mysqld(+0x60b54b)[0x5583efb7c54b] /usr/libexec/mysqld(_Z19ha_commit_one_phaseP3THDb+0x80)[0x5583efa17ac0] /usr/libexec/mysqld(_Z15ha_commit_transP3THDb+0x356)[0x5583efa18236] /usr/libexec/mysqld(_Z17trans_commit_stmtP3THD+0x1b)[0x5583ef9ab3bb] /usr/libexec/mysqld(_Z21mysql_execute_commandP3THD+0x3dc)[0x5583ef8e39ec] /usr/libexec/mysqld(_Z11mysql_parseP3THDPcjP12Parser_state+0x125)[0x5583ef8ea445] /usr/libexec/mysqld(_Z16dispatch_command19enum_server_commandP3THDPcj+0x1750)[0x5583ef8ec4a0] /usr/libexec/mysqld(_Z24do_handle_one_connectionP3THD+0x1c2)[0x5583ef99ea22] /usr/libexec/mysqld(handle_one_connection+0x4a)[0x5583ef99eaca] pthread_create.c:0(start_thread)[0x7fc95c7d0dd5] /lib64/libc.so.6(clone+0x6d)[0x7fc95afc9ead] Trying to get some variables. Some pointers may be invalid and cause the dump to abort. Query (0x7fc9100116e8): UPDATE `ipaddresses` SET `lastSeen`='2019-04-24 02:00:01' WHERE `id`='5956' Connection ID (thread ID): 12 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=on,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=off,table_elimination=on,extended_keys=off 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. 190424 02:00:13 mysqld_safe Number of processes running now: 0 190424 02:00:13 mysqld_safe mysqld restarted 190424 2:00:13 [Note] /usr/libexec/mysqld (mysqld 5.5.60-MariaDB) starting as process 32357 ... 190424 2:00:13 InnoDB: The InnoDB memory heap is disabled 190424 2:00:13 InnoDB: Mutexes and rw_locks use GCC atomic builtins 190424 2:00:13 InnoDB: Compressed tables use zlib 1.2.7 190424 2:00:13 InnoDB: Using Linux native AIO 190424 2:00:13 InnoDB: Initializing buffer pool, size = 128.0M 190424 2:00:13 InnoDB: Completed initialization of buffer pool 190424 2:00:13 InnoDB: highest supported file format is Barracuda. 190424 2:00:13 InnoDB: Starting crash recovery from checkpoint LSN=18203052 InnoDB: Restoring possible half-written data pages from the doublewrite buffer... 190424 2:00:13 InnoDB: Starting final batch to recover 3 pages from redo log 190424 2:00:14 InnoDB: Waiting for the background threads to start 190424 2:00:15 Percona XtraDB (http://www.percona.com) 5.5.59-MariaDB-38.11 started; log sequence number 18241152 190424 2:00:15 [Note] Plugin 'FEEDBACK' is disabled. 190424 2:00:15 [Note] Server socket created on IP: '0.0.0.0'. 190424 2:00:15 [Note] Event Scheduler: Loaded 0 events 190424 2:00:15 [Note] /usr/libexec/mysqld: ready for connections. Version: '5.5.60-MariaDB' socket: '/data/mysql/mysql.sock' port: 3306 MariaDB Server 190424 2:15:13 InnoDB: Assertion failure in thread 140037076174592 in file fut0lst.ic line 83 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: http://dev.mysql.com/doc/refman/5.5/en/forcing-innodb-recovery.html InnoDB: about forcing recovery. 190424 2:15:13 [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 http://kb.askmonty.org/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: 5.5.60-MariaDB key_buffer_size=134217728 read_buffer_size=131072 max_used_connections=3 max_threads=153 thread_count=1 It is possible that mysqld could use up to key_buffer_size + (read_buffer_size + sort_buffer_size)*max_threads = 466718 K bytes of memory Hope that's ok; if not, decrease some variables in the equation. Thread pointer: 0x55ba553ea1f0 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 = 0x7f5cec2e3d80 thread_stack 0x48000 /usr/libexec/mysqld(my_print_stacktrace+0x3d)[0x55ba535c5cbd] /usr/libexec/mysqld(handle_fatal_signal+0x515)[0x55ba531da4a5] sigaction.c:0(__restore_rt)[0x7f5cf36e95d0] :0(__GI_raise)[0x7f5cf1e13207] :0(__GI_abort)[0x7f5cf1e148f8] /usr/libexec/mysqld(+0x2d73b7)[0x55ba5300d3b7] /usr/libexec/mysqld(+0x6f87d0)[0x55ba5342e7d0] /usr/libexec/mysqld(+0x657ade)[0x55ba5338dade] /usr/libexec/mysqld(+0x671153)[0x55ba533a7153] /usr/libexec/mysqld(+0x666faf)[0x55ba5339cfaf] /usr/libexec/mysqld(+0x668d94)[0x55ba5339ed94] /usr/libexec/mysqld(+0x66a6c7)[0x55ba533a06c7] /usr/libexec/mysqld(+0x60a5a0)[0x55ba533405a0] /usr/libexec/mysqld(+0x60b54b)[0x55ba5334154b] /usr/libexec/mysqld(_Z19ha_commit_one_phaseP3THDb+0x80)[0x55ba531dcac0] /usr/libexec/mysqld(_Z15ha_commit_transP3THDb+0x356)[0x55ba531dd236] /usr/libexec/mysqld(_Z17trans_commit_stmtP3THD+0x1b)[0x55ba531703bb] /usr/libexec/mysqld(_Z21mysql_execute_commandP3THD+0x3dc)[0x55ba530a89ec] /usr/libexec/mysqld(_Z11mysql_parseP3THDPcjP12Parser_state+0x125)[0x55ba530af445] /usr/libexec/mysqld(_Z16dispatch_command19enum_server_commandP3THDPcj+0x1750)[0x55ba530b14a0] /usr/libexec/mysqld(_Z24do_handle_one_connectionP3THD+0x1c2)[0x55ba53163a22] /usr/libexec/mysqld(handle_one_connection+0x4a)[0x55ba53163aca] pthread_create.c:0(start_thread)[0x7f5cf36e1dd5] /lib64/libc.so.6(clone+0x6d)[0x7f5cf1edaead] Trying to get some variables. Some pointers may be invalid and cause the dump to abort. Query (0x7f5cac004c18): UPDATE `ipaddresses` SET `lastSeen`='2019-04-24 02:15:01' WHERE `id`='5956' Connection ID (thread ID): 12 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=on,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=off,table_elimination=on,extended_keys=off 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. 190424 02:15:14 mysqld_safe Number of processes running now: 0 190424 02:15:14 mysqld_safe mysqld restarted 190424 2:15:14 [Note] /usr/libexec/mysqld (mysqld 5.5.60-MariaDB) starting as process 1401 ... 190424 2:15:14 InnoDB: The InnoDB memory heap is disabled 190424 2:15:14 InnoDB: Mutexes and rw_locks use GCC atomic builtins 190424 2:15:14 InnoDB: Compressed tables use zlib 1.2.7 190424 2:15:14 InnoDB: Using Linux native AIO 190424 2:15:14 InnoDB: Initializing buffer pool, size = 128.0M 190424 2:15:14 InnoDB: Completed initialization of buffer pool 190424 2:15:14 InnoDB: highest supported file format is Barracuda. 190424 2:15:14 InnoDB: Starting crash recovery from checkpoint LSN=18247742 InnoDB: Restoring possible half-written data pages from the doublewrite buffer... 190424 2:15:14 InnoDB: Starting final batch to recover 3 pages from redo log 190424 2:15:14 InnoDB: Waiting for the background threads to start 190424 2:15:15 Percona XtraDB (http://www.percona.com) 5.5.59-MariaDB-38.11 started; log sequence number 18282100 190424 2:15:15 [Note] Plugin 'FEEDBACK' is disabled. 190424 2:15:15 [Note] Server socket created on IP: '0.0.0.0'. 190424 2:15:15 [Note] Event Scheduler: Loaded 0 events 190424 2:15:15 [Note] /usr/libexec/mysqld: ready for connections. Version: '5.5.60-MariaDB' socket: '/data/mysql/mysql.sock' port: 3306 MariaDB Server 190424 2:30:14 InnoDB: Assertion failure in thread 140372821993216 in file fut0lst.ic line 83 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: http://dev.mysql.com/doc/refman/5.5/en/forcing-innodb-recovery.html InnoDB: about forcing recovery. 190424 2:30:14 [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 http://kb.askmonty.org/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: 5.5.60-MariaDB key_buffer_size=134217728 read_buffer_size=131072 max_used_connections=3 max_threads=153 thread_count=1 It is possible that mysqld could use up to key_buffer_size + (read_buffer_size + sort_buffer_size)*max_threads = 466718 K bytes of memory Hope that's ok; if not, decrease some variables in the equation. Thread pointer: 0x56148d08f1f0 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 = 0x7fab1830dd80 thread_stack 0x48000 /usr/libexec/mysqld(my_print_stacktrace+0x3d)[0x5614899dccbd] /usr/libexec/mysqld(handle_fatal_signal+0x515)[0x5614895f14a5] sigaction.c:0(__restore_rt)[0x7fab1f75d5d0] :0(__GI_raise)[0x7fab1de87207] :0(__GI_abort)[0x7fab1de888f8] /usr/libexec/mysqld(+0x2d73b7)[0x5614894243b7] /usr/libexec/mysqld(+0x6f87d0)[0x5614898457d0] /usr/libexec/mysqld(+0x657ade)[0x5614897a4ade] /usr/libexec/mysqld(+0x671153)[0x5614897be153] /usr/libexec/mysqld(+0x666faf)[0x5614897b3faf] /usr/libexec/mysqld(+0x668d94)[0x5614897b5d94] /usr/libexec/mysqld(+0x66a6c7)[0x5614897b76c7] /usr/libexec/mysqld(+0x60a5a0)[0x5614897575a0] /usr/libexec/mysqld(+0x60b54b)[0x56148975854b] /usr/libexec/mysqld(_Z19ha_commit_one_phaseP3THDb+0x80)[0x5614895f3ac0] /usr/libexec/mysqld(_Z15ha_commit_transP3THDb+0x356)[0x5614895f4236] /usr/libexec/mysqld(_Z17trans_commit_stmtP3THD+0x1b)[0x5614895873bb] /usr/libexec/mysqld(_Z21mysql_execute_commandP3THD+0x3dc)[0x5614894bf9ec] /usr/libexec/mysqld(_Z11mysql_parseP3THDPcjP12Parser_state+0x125)[0x5614894c6445] /usr/libexec/mysqld(_Z16dispatch_command19enum_server_commandP3THDPcj+0x1750)[0x5614894c84a0] /usr/libexec/mysqld(_Z24do_handle_one_connectionP3THD+0x1c2)[0x56148957aa22] /usr/libexec/mysqld(handle_one_connection+0x4a)[0x56148957aaca] pthread_create.c:0(start_thread)[0x7fab1f755dd5] /lib64/libc.so.6(clone+0x6d)[0x7fab1df4eead] Trying to get some variables. Some pointers may be invalid and cause the dump to abort. Query (0x7faad8004c18): UPDATE `ipaddresses` SET `lastSeen`='2019-04-24 02:30:02' WHERE `id`='5956' Connection ID (thread ID): 12 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=on,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=off,table_elimination=on,extended_keys=off 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. 190424 02:30:14 mysqld_safe Number of processes running now: 0 190424 02:30:14 mysqld_safe mysqld restarted 190424 2:30:14 [Note] /usr/libexec/mysqld (mysqld 5.5.60-MariaDB) starting as process 3381 ... 190424 2:30:14 InnoDB: The InnoDB memory heap is disabled 190424 2:30:14 InnoDB: Mutexes and rw_locks use GCC atomic builtins 190424 2:30:14 InnoDB: Compressed tables use zlib 1.2.7 190424 2:30:14 InnoDB: Using Linux native AIO 190424 2:30:14 InnoDB: Initializing buffer pool, size = 128.0M 190424 2:30:14 InnoDB: Completed initialization of buffer pool 190424 2:30:14 InnoDB: highest supported file format is Barracuda. 190424 2:30:14 InnoDB: Starting crash recovery from checkpoint LSN=18289408 InnoDB: Restoring possible half-written data pages from the doublewrite buffer... 190424 2:30:14 InnoDB: Starting final batch to recover 3 pages from redo log 190424 2:30:15 InnoDB: Waiting for the background threads to start 190424 2:30:16 Percona XtraDB (http://www.percona.com) 5.5.59-MariaDB-38.11 started; log sequence number 18322894 190424 2:30:16 [Note] Plugin 'FEEDBACK' is disabled. 190424 2:30:16 [Note] Server socket created on IP: '0.0.0.0'. 190424 2:30:16 [Note] Event Scheduler: Loaded 0 events 190424 2:30:16 [Note] /usr/libexec/mysqld: ready for connections. Version: '5.5.60-MariaDB' socket: '/data/mysql/mysql.sock' port: 3306 MariaDB Server 190424 2:45:13 InnoDB: Assertion failure in thread 140600521598720 in file fut0lst.ic line 83 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: http://dev.mysql.com/doc/refman/5.5/en/forcing-innodb-recovery.html InnoDB: about forcing recovery. 190424 2:45:13 [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 http://kb.askmonty.org/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: 5.5.60-MariaDB key_buffer_size=134217728 read_buffer_size=131072 max_used_connections=3 max_threads=153 thread_count=1 It is possible that mysqld could use up to key_buffer_size + (read_buffer_size + sort_buffer_size)*max_threads = 466718 K bytes of memory Hope that's ok; if not, decrease some variables in the equation. Thread pointer: 0x556292bcb570 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 = 0x7fe01c251d80 thread_stack 0x48000 /usr/libexec/mysqld(my_print_stacktrace+0x3d)[0x5562904b8cbd] /usr/libexec/mysqld(handle_fatal_signal+0x515)[0x5562900cd4a5] sigaction.c:0(__restore_rt)[0x7fe02169d5d0] :0(__GI_raise)[0x7fe01fdc7207] :0(__GI_abort)[0x7fe01fdc88f8] /usr/libexec/mysqld(+0x2d73b7)[0x55628ff003b7] /usr/libexec/mysqld(+0x6f87d0)[0x5562903217d0] /usr/libexec/mysqld(+0x657ade)[0x556290280ade] /usr/libexec/mysqld(+0x671153)[0x55629029a153] /usr/libexec/mysqld(+0x666faf)[0x55629028ffaf] /usr/libexec/mysqld(+0x668d94)[0x556290291d94] /usr/libexec/mysqld(+0x66a6c7)[0x5562902936c7] /usr/libexec/mysqld(+0x60a5a0)[0x5562902335a0] /usr/libexec/mysqld(+0x60b54b)[0x55629023454b] /usr/libexec/mysqld(_Z19ha_commit_one_phaseP3THDb+0x80)[0x5562900cfac0] /usr/libexec/mysqld(_Z15ha_commit_transP3THDb+0x356)[0x5562900d0236] /usr/libexec/mysqld(_Z17trans_commit_stmtP3THD+0x1b)[0x5562900633bb] /usr/libexec/mysqld(_Z21mysql_execute_commandP3THD+0x3dc)[0x55628ff9b9ec] /usr/libexec/mysqld(_Z11mysql_parseP3THDPcjP12Parser_state+0x125)[0x55628ffa2445] /usr/libexec/mysqld(_Z16dispatch_command19enum_server_commandP3THDPcj+0x1750)[0x55628ffa44a0] /usr/libexec/mysqld(_Z24do_handle_one_connectionP3THD+0x1c2)[0x556290056a22] /usr/libexec/mysqld(handle_one_connection+0x4a)[0x556290056aca] pthread_create.c:0(start_thread)[0x7fe021695dd5] /lib64/libc.so.6(clone+0x6d)[0x7fe01fe8eead] Trying to get some variables. Some pointers may be invalid and cause the dump to abort. Query (0x7fdfe0004c18): UPDATE `ipaddresses` SET `lastSeen`='2019-04-24 02:45:01' WHERE `id`='5956' Connection ID (thread ID): 12 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=on,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=off,table_elimination=on,extended_keys=off 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. 190424 02:45:13 mysqld_safe Number of processes running now: 0 190424 02:45:13 mysqld_safe mysqld restarted 190424 2:45:13 [Note] /usr/libexec/mysqld (mysqld 5.5.60-MariaDB) starting as process 4961 ... 190424 2:45:13 InnoDB: The InnoDB memory heap is disabled 190424 2:45:13 InnoDB: Mutexes and rw_locks use GCC atomic builtins 190424 2:45:13 InnoDB: Compressed tables use zlib 1.2.7 190424 2:45:13 InnoDB: Using Linux native AIO 190424 2:45:13 InnoDB: Initializing buffer pool, size = 128.0M 190424 2:45:13 InnoDB: Completed initialization of buffer pool 190424 2:45:13 InnoDB: highest supported file format is Barracuda. 190424 2:45:13 InnoDB: Starting crash recovery from checkpoint LSN=18329276 InnoDB: Restoring possible half-written data pages from the doublewrite buffer... 190424 2:45:13 InnoDB: Starting final batch to recover 3 pages from redo log 190424 2:45:14 InnoDB: Waiting for the background threads to start 190424 2:45:15 Percona XtraDB (http://www.percona.com) 5.5.59-MariaDB-38.11 started; log sequence number 18362138 190424 2:45:15 [Note] Plugin 'FEEDBACK' is disabled. 190424 2:45:15 [Note] Server socket created on IP: '0.0.0.0'. 190424 2:45:15 [Note] Event Scheduler: Loaded 0 events 190424 2:45:15 [Note] /usr/libexec/mysqld: ready for connections. Version: '5.5.60-MariaDB' socket: '/data/mysql/mysql.sock' port: 3306 MariaDB Server 190424 3:00:13 InnoDB: Assertion failure in thread 139995215935232 in file fut0lst.ic line 83 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: http://dev.mysql.com/doc/refman/5.5/en/forcing-innodb-recovery.html InnoDB: about forcing recovery. 190424 3:00:13 [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 http://kb.askmonty.org/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: 5.5.60-MariaDB key_buffer_size=134217728 read_buffer_size=131072 max_used_connections=3 max_threads=153 thread_count=1 It is possible that mysqld could use up to key_buffer_size + (read_buffer_size + sort_buffer_size)*max_threads = 466718 K bytes of memory Hope that's ok; if not, decrease some variables in the equation. Thread pointer: 0x559218ca83b0 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 = 0x7f532d1dad80 thread_stack 0x48000 /usr/libexec/mysqld(my_print_stacktrace+0x3d)[0x559216384cbd] /usr/libexec/mysqld(handle_fatal_signal+0x515)[0x559215f994a5] sigaction.c:0(__restore_rt)[0x7f534a5005d0] :0(__GI_raise)[0x7f5348c2a207] :0(__GI_abort)[0x7f5348c2b8f8] /usr/libexec/mysqld(+0x2d73b7)[0x559215dcc3b7] /usr/libexec/mysqld(+0x6f87d0)[0x5592161ed7d0] /usr/libexec/mysqld(+0x657ade)[0x55921614cade] /usr/libexec/mysqld(+0x671153)[0x559216166153] /usr/libexec/mysqld(+0x666faf)[0x55921615bfaf] /usr/libexec/mysqld(+0x668d94)[0x55921615dd94] /usr/libexec/mysqld(+0x66a6c7)[0x55921615f6c7] /usr/libexec/mysqld(+0x60a5a0)[0x5592160ff5a0] /usr/libexec/mysqld(+0x60b54b)[0x55921610054b] /usr/libexec/mysqld(_Z19ha_commit_one_phaseP3THDb+0x80)[0x559215f9bac0] /usr/libexec/mysqld(_Z15ha_commit_transP3THDb+0x356)[0x559215f9c236] /usr/libexec/mysqld(_Z17trans_commit_stmtP3THD+0x1b)[0x559215f2f3bb] /usr/libexec/mysqld(_Z21mysql_execute_commandP3THD+0x3dc)[0x559215e679ec] /usr/libexec/mysqld(_Z11mysql_parseP3THDPcjP12Parser_state+0x125)[0x559215e6e445] /usr/libexec/mysqld(_Z16dispatch_command19enum_server_commandP3THDPcj+0x1750)[0x559215e704a0] /usr/libexec/mysqld(_Z24do_handle_one_connectionP3THD+0x1c2)[0x559215f22a22] /usr/libexec/mysqld(handle_one_connection+0x4a)[0x559215f22aca] pthread_create.c:0(start_thread)[0x7f534a4f8dd5] /lib64/libc.so.6(clone+0x6d)[0x7f5348cf1ead] Trying to get some variables. Some pointers may be invalid and cause the dump to abort. Query (0x7f5304004c18): UPDATE `ipaddresses` SET `lastSeen`='2019-04-24 03:00:01' WHERE `id`='5956' Connection ID (thread ID): 12 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=on,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=off,table_elimination=on,extended_keys=off 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. 190424 03:00:13 mysqld_safe Number of processes running now: 0 190424 03:00:13 mysqld_safe mysqld restarted 190424 3:00:13 [Note] /usr/libexec/mysqld (mysqld 5.5.60-MariaDB) starting as process 6948 ... 190424 3:00:13 InnoDB: The InnoDB memory heap is disabled 190424 3:00:13 InnoDB: Mutexes and rw_locks use GCC atomic builtins 190424 3:00:13 InnoDB: Compressed tables use zlib 1.2.7 190424 3:00:13 InnoDB: Using Linux native AIO 190424 3:00:13 InnoDB: Initializing buffer pool, size = 128.0M 190424 3:00:14 InnoDB: Completed initialization of buffer pool 190424 3:00:14 InnoDB: highest supported file format is Barracuda. 190424 3:00:14 InnoDB: Starting crash recovery from checkpoint LSN=18369332 InnoDB: Restoring possible half-written data pages from the doublewrite buffer... 190424 3:00:14 InnoDB: Starting final batch to recover 3 pages from redo log 190424 3:00:14 InnoDB: Waiting for the background threads to start 190424 3:00:15 Percona XtraDB (http://www.percona.com) 5.5.59-MariaDB-38.11 started; log sequence number 18402068 190424 3:00:15 [Note] Plugin 'FEEDBACK' is disabled. 190424 3:00:15 [Note] Server socket created on IP: '0.0.0.0'. 190424 3:00:15 [Note] Event Scheduler: Loaded 0 events 190424 3:00:15 [Note] /usr/libexec/mysqld: ready for connections. Version: '5.5.60-MariaDB' socket: '/data/mysql/mysql.sock' port: 3306 MariaDB Server 190424 3:15:14 InnoDB: Assertion failure in thread 140310410397440 in file fut0lst.ic line 83 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: http://dev.mysql.com/doc/refman/5.5/en/forcing-innodb-recovery.html InnoDB: about forcing recovery. 190424 3:15:14 [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 http://kb.askmonty.org/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: 5.5.60-MariaDB key_buffer_size=134217728 read_buffer_size=131072 max_used_connections=3 max_threads=153 thread_count=1 It is possible that mysqld could use up to key_buffer_size + (read_buffer_size + sort_buffer_size)*max_threads = 466718 K bytes of memory Hope that's ok; if not, decrease some variables in the equation. Thread pointer: 0x5587628e2730 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 = 0x7f9c902b7d80 thread_stack 0x48000 /usr/libexec/mysqld(my_print_stacktrace+0x3d)[0x55875f871cbd] /usr/libexec/mysqld(handle_fatal_signal+0x515)[0x55875f4864a5] sigaction.c:0(__restore_rt)[0x7f9c961175d0] :0(__GI_raise)[0x7f9c94841207] :0(__GI_abort)[0x7f9c948428f8] /usr/libexec/mysqld(+0x2d73b7)[0x55875f2b93b7] /usr/libexec/mysqld(+0x6f87d0)[0x55875f6da7d0] /usr/libexec/mysqld(+0x657ade)[0x55875f639ade] /usr/libexec/mysqld(+0x671153)[0x55875f653153] /usr/libexec/mysqld(+0x666faf)[0x55875f648faf] /usr/libexec/mysqld(+0x668d94)[0x55875f64ad94] /usr/libexec/mysqld(+0x66a6c7)[0x55875f64c6c7] /usr/libexec/mysqld(+0x60a5a0)[0x55875f5ec5a0] /usr/libexec/mysqld(+0x60b54b)[0x55875f5ed54b] /usr/libexec/mysqld(_Z19ha_commit_one_phaseP3THDb+0x80)[0x55875f488ac0] /usr/libexec/mysqld(_Z15ha_commit_transP3THDb+0x356)[0x55875f489236] /usr/libexec/mysqld(_Z17trans_commit_stmtP3THD+0x1b)[0x55875f41c3bb] /usr/libexec/mysqld(_Z21mysql_execute_commandP3THD+0x3dc)[0x55875f3549ec] /usr/libexec/mysqld(_Z11mysql_parseP3THDPcjP12Parser_state+0x125)[0x55875f35b445] /usr/libexec/mysqld(_Z16dispatch_command19enum_server_commandP3THDPcj+0x1750)[0x55875f35d4a0] /usr/libexec/mysqld(_Z24do_handle_one_connectionP3THD+0x1c2)[0x55875f40fa22] /usr/libexec/mysqld(handle_one_connection+0x4a)[0x55875f40faca] pthread_create.c:0(start_thread)[0x7f9c9610fdd5] /lib64/libc.so.6(clone+0x6d)[0x7f9c94908ead] Trying to get some variables. Some pointers may be invalid and cause the dump to abort. Query (0x7f9c50004c18): UPDATE `ipaddresses` SET `lastSeen`='2019-04-24 03:15:02' WHERE `id`='5956' Connection ID (thread ID): 12 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=on,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=off,table_elimination=on,extended_keys=off 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. 190424 03:15:14 mysqld_safe Number of processes running now: 0 190424 03:15:14 mysqld_safe mysqld restarted 190424 3:15:14 [Note] /usr/libexec/mysqld (mysqld 5.5.60-MariaDB) starting as process 8458 ... 190424 3:15:14 InnoDB: The InnoDB memory heap is disabled 190424 3:15:14 InnoDB: Mutexes and rw_locks use GCC atomic builtins 190424 3:15:14 InnoDB: Compressed tables use zlib 1.2.7 190424 3:15:14 InnoDB: Using Linux native AIO 190424 3:15:14 InnoDB: Initializing buffer pool, size = 128.0M 190424 3:15:14 InnoDB: Completed initialization of buffer pool 190424 3:15:14 InnoDB: highest supported file format is Barracuda. 190424 3:15:14 InnoDB: Starting crash recovery from checkpoint LSN=18408307 InnoDB: Restoring possible half-written data pages from the doublewrite buffer... 190424 3:15:14 InnoDB: Starting final batch to recover 3 pages from redo log 190424 3:15:15 InnoDB: Waiting for the background threads to start 190424 3:15:16 Percona XtraDB (http://www.percona.com) 5.5.59-MariaDB-38.11 started; log sequence number 18441022 190424 3:15:16 [Note] Plugin 'FEEDBACK' is disabled. 190424 3:15:16 [Note] Server socket created on IP: '0.0.0.0'. 190424 3:15:16 [Note] Event Scheduler: Loaded 0 events 190424 3:15:16 [Note] /usr/libexec/mysqld: ready for connections. Version: '5.5.60-MariaDB' socket: '/data/mysql/mysql.sock' port: 3306 MariaDB Server 190424 3:30:13 InnoDB: Assertion failure in thread 139848835725056 in file fut0lst.ic line 83 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: http://dev.mysql.com/doc/refman/5.5/en/forcing-innodb-recovery.html InnoDB: about forcing recovery. 190424 3:30:13 [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 http://kb.askmonty.org/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: 5.5.60-MariaDB key_buffer_size=134217728 read_buffer_size=131072 max_used_connections=3 max_threads=153 thread_count=1 It is possible that mysqld could use up to key_buffer_size + (read_buffer_size + sort_buffer_size)*max_threads = 466718 K bytes of memory Hope that's ok; if not, decrease some variables in the equation. Thread pointer: 0x5555b464b8f0 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 = 0x7f31182ced80 thread_stack 0x48000 /usr/libexec/mysqld(my_print_stacktrace+0x3d)[0x5555b205ecbd] /usr/libexec/mysqld(handle_fatal_signal+0x515)[0x5555b1c734a5] sigaction.c:0(__restore_rt)[0x7f311e12e5d0] :0(__GI_raise)[0x7f311c858207] :0(__GI_abort)[0x7f311c8598f8] /usr/libexec/mysqld(+0x2d73b7)[0x5555b1aa63b7] /usr/libexec/mysqld(+0x6f87d0)[0x5555b1ec77d0] /usr/libexec/mysqld(+0x657ade)[0x5555b1e26ade] /usr/libexec/mysqld(+0x671153)[0x5555b1e40153] /usr/libexec/mysqld(+0x666faf)[0x5555b1e35faf] /usr/libexec/mysqld(+0x668d94)[0x5555b1e37d94] /usr/libexec/mysqld(+0x66a6c7)[0x5555b1e396c7] /usr/libexec/mysqld(+0x60a5a0)[0x5555b1dd95a0] /usr/libexec/mysqld(+0x60b54b)[0x5555b1dda54b] /usr/libexec/mysqld(_Z19ha_commit_one_phaseP3THDb+0x80)[0x5555b1c75ac0] /usr/libexec/mysqld(_Z15ha_commit_transP3THDb+0x356)[0x5555b1c76236] /usr/libexec/mysqld(_Z17trans_commit_stmtP3THD+0x1b)[0x5555b1c093bb] /usr/libexec/mysqld(_Z21mysql_execute_commandP3THD+0x3dc)[0x5555b1b419ec] /usr/libexec/mysqld(_Z11mysql_parseP3THDPcjP12Parser_state+0x125)[0x5555b1b48445] /usr/libexec/mysqld(_Z16dispatch_command19enum_server_commandP3THDPcj+0x1750)[0x5555b1b4a4a0] /usr/libexec/mysqld(_Z24do_handle_one_connectionP3THD+0x1c2)[0x5555b1bfca22] /usr/libexec/mysqld(handle_one_connection+0x4a)[0x5555b1bfcaca] pthread_create.c:0(start_thread)[0x7f311e126dd5] /lib64/libc.so.6(clone+0x6d)[0x7f311c91fead] Trying to get some variables. Some pointers may be invalid and cause the dump to abort. Query (0x7f30d8004c18): UPDATE `ipaddresses` SET `lastSeen`='2019-04-24 03:30:01' WHERE `id`='5956' Connection ID (thread ID): 12 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=on,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=off,table_elimination=on,extended_keys=off 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. 190424 03:30:14 mysqld_safe Number of processes running now: 0 190424 03:30:14 mysqld_safe mysqld restarted 190424 3:30:14 [Note] /usr/libexec/mysqld (mysqld 5.5.60-MariaDB) starting as process 10426 ... 190424 3:30:14 InnoDB: The InnoDB memory heap is disabled 190424 3:30:14 InnoDB: Mutexes and rw_locks use GCC atomic builtins 190424 3:30:14 InnoDB: Compressed tables use zlib 1.2.7 190424 3:30:14 InnoDB: Using Linux native AIO 190424 3:30:14 InnoDB: Initializing buffer pool, size = 128.0M 190424 3:30:14 InnoDB: Completed initialization of buffer pool 190424 3:30:14 InnoDB: highest supported file format is Barracuda. 190424 3:30:14 InnoDB: Starting crash recovery from checkpoint LSN=18447027 InnoDB: Restoring possible half-written data pages from the doublewrite buffer... 190424 3:30:14 InnoDB: Starting final batch to recover 3 pages from redo log 190424 3:30:14 InnoDB: Waiting for the background threads to start 190424 3:30:15 Percona XtraDB (http://www.percona.com) 5.5.59-MariaDB-38.11 started; log sequence number 18478371 190424 3:30:15 [Note] Plugin 'FEEDBACK' is disabled. 190424 3:30:15 [Note] Server socket created on IP: '0.0.0.0'. 190424 3:30:15 [Note] Event Scheduler: Loaded 0 events 190424 3:30:15 [Note] /usr/libexec/mysqld: ready for connections. Version: '5.5.60-MariaDB' socket: '/data/mysql/mysql.sock' port: 3306 MariaDB Server 190424 3:45:13 InnoDB: Assertion failure in thread 140047947216640 in file fut0lst.ic line 83 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: http://dev.mysql.com/doc/refman/5.5/en/forcing-innodb-recovery.html InnoDB: about forcing recovery. 190424 3:45:13 [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 http://kb.askmonty.org/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: 5.5.60-MariaDB key_buffer_size=134217728 read_buffer_size=131072 max_used_connections=3 max_threads=153 thread_count=1 It is possible that mysqld could use up to key_buffer_size + (read_buffer_size + sort_buffer_size)*max_threads = 466718 K bytes of memory Hope that's ok; if not, decrease some variables in the equation. Thread pointer: 0x55cf0eb548f0 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 = 0x7f5f74252d80 thread_stack 0x48000 /usr/libexec/mysqld(my_print_stacktrace+0x3d)[0x55cf0b78bcbd] /usr/libexec/mysqld(handle_fatal_signal+0x515)[0x55cf0b3a04a5] sigaction.c:0(__restore_rt)[0x7f5f79e9f5d0] :0(__GI_raise)[0x7f5f785c9207] :0(__GI_abort)[0x7f5f785ca8f8] /usr/libexec/mysqld(+0x2d73b7)[0x55cf0b1d33b7] /usr/libexec/mysqld(+0x6f87d0)[0x55cf0b5f47d0] /usr/libexec/mysqld(+0x657ade)[0x55cf0b553ade] /usr/libexec/mysqld(+0x671153)[0x55cf0b56d153] /usr/libexec/mysqld(+0x666faf)[0x55cf0b562faf] /usr/libexec/mysqld(+0x668d94)[0x55cf0b564d94] /usr/libexec/mysqld(+0x66a6c7)[0x55cf0b5666c7] /usr/libexec/mysqld(+0x60a5a0)[0x55cf0b5065a0] /usr/libexec/mysqld(+0x60b54b)[0x55cf0b50754b] /usr/libexec/mysqld(_Z19ha_commit_one_phaseP3THDb+0x80)[0x55cf0b3a2ac0] /usr/libexec/mysqld(_Z15ha_commit_transP3THDb+0x356)[0x55cf0b3a3236] /usr/libexec/mysqld(_Z17trans_commit_stmtP3THD+0x1b)[0x55cf0b3363bb] /usr/libexec/mysqld(_Z21mysql_execute_commandP3THD+0x3dc)[0x55cf0b26e9ec] /usr/libexec/mysqld(_Z11mysql_parseP3THDPcjP12Parser_state+0x125)[0x55cf0b275445] /usr/libexec/mysqld(_Z16dispatch_command19enum_server_commandP3THDPcj+0x1750)[0x55cf0b2774a0] /usr/libexec/mysqld(_Z24do_handle_one_connectionP3THD+0x1c2)[0x55cf0b329a22] /usr/libexec/mysqld(handle_one_connection+0x4a)[0x55cf0b329aca] pthread_create.c:0(start_thread)[0x7f5f79e97dd5] /lib64/libc.so.6(clone+0x6d)[0x7f5f78690ead] Trying to get some variables. Some pointers may be invalid and cause the dump to abort. Query (0x7f5f34004c18): UPDATE `ipaddresses` SET `lastSeen`='2019-04-24 03:45:01' WHERE `id`='5956' Connection ID (thread ID): 12 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=on,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=off,table_elimination=on,extended_keys=off 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. 190424 03:45:13 mysqld_safe Number of processes running now: 0 190424 03:45:13 mysqld_safe mysqld restarted 190424 3:45:13 [Note] /usr/libexec/mysqld (mysqld 5.5.60-MariaDB) starting as process 11925 ... 190424 3:45:13 InnoDB: The InnoDB memory heap is disabled 190424 3:45:13 InnoDB: Mutexes and rw_locks use GCC atomic builtins 190424 3:45:13 InnoDB: Compressed tables use zlib 1.2.7 190424 3:45:13 InnoDB: Using Linux native AIO 190424 3:45:13 InnoDB: Initializing buffer pool, size = 128.0M 190424 3:45:13 InnoDB: Completed initialization of buffer pool 190424 3:45:13 InnoDB: highest supported file format is Barracuda. 190424 3:45:13 InnoDB: Starting crash recovery from checkpoint LSN=18484377 InnoDB: Restoring possible half-written data pages from the doublewrite buffer... 190424 3:45:13 InnoDB: Starting final batch to recover 3 pages from redo log 190424 3:45:14 InnoDB: Waiting for the background threads to start 190424 3:45:15 Percona XtraDB (http://www.percona.com) 5.5.59-MariaDB-38.11 started; log sequence number 18515683 190424 3:45:15 [Note] Plugin 'FEEDBACK' is disabled. 190424 3:45:15 [Note] Server socket created on IP: '0.0.0.0'. 190424 3:45:15 [Note] Event Scheduler: Loaded 0 events 190424 3:45:15 [Note] /usr/libexec/mysqld: ready for connections. Version: '5.5.60-MariaDB' socket: '/data/mysql/mysql.sock' port: 3306 MariaDB Server 190424 4:00:13 InnoDB: Assertion failure in thread 140560658134784 in file fut0lst.ic line 83 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: http://dev.mysql.com/doc/refman/5.5/en/forcing-innodb-recovery.html InnoDB: about forcing recovery. 190424 4:00:13 [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 http://kb.askmonty.org/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: 5.5.60-MariaDB key_buffer_size=134217728 read_buffer_size=131072 max_used_connections=3 max_threads=153 thread_count=1 It is possible that mysqld could use up to key_buffer_size + (read_buffer_size + sort_buffer_size)*max_threads = 466718 K bytes of memory Hope that's ok; if not, decrease some variables in the equation. Thread pointer: 0x563d435271f0 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 = 0x7fd6d418ed80 thread_stack 0x48000 /usr/libexec/mysqld(my_print_stacktrace+0x3d)[0x563d40595cbd] /usr/libexec/mysqld(handle_fatal_signal+0x515)[0x563d401aa4a5] sigaction.c:0(__restore_rt)[0x7fd6f14c65d0] :0(__GI_raise)[0x7fd6efbf0207] :0(__GI_abort)[0x7fd6efbf18f8] /usr/libexec/mysqld(+0x2d73b7)[0x563d3ffdd3b7] /usr/libexec/mysqld(+0x6f87d0)[0x563d403fe7d0] /usr/libexec/mysqld(+0x657ade)[0x563d4035dade] /usr/libexec/mysqld(+0x671153)[0x563d40377153] /usr/libexec/mysqld(+0x666faf)[0x563d4036cfaf] /usr/libexec/mysqld(+0x668d94)[0x563d4036ed94] /usr/libexec/mysqld(+0x66a6c7)[0x563d403706c7] /usr/libexec/mysqld(+0x60a5a0)[0x563d403105a0] /usr/libexec/mysqld(+0x60b54b)[0x563d4031154b] /usr/libexec/mysqld(_Z19ha_commit_one_phaseP3THDb+0x80)[0x563d401acac0] /usr/libexec/mysqld(_Z15ha_commit_transP3THDb+0x356)[0x563d401ad236] /usr/libexec/mysqld(_Z17trans_commit_stmtP3THD+0x1b)[0x563d401403bb] /usr/libexec/mysqld(_Z21mysql_execute_commandP3THD+0x3dc)[0x563d400789ec] /usr/libexec/mysqld(_Z11mysql_parseP3THDPcjP12Parser_state+0x125)[0x563d4007f445] /usr/libexec/mysqld(_Z16dispatch_command19enum_server_commandP3THDPcj+0x1750)[0x563d400814a0] /usr/libexec/mysqld(_Z24do_handle_one_connectionP3THD+0x1c2)[0x563d40133a22] /usr/libexec/mysqld(handle_one_connection+0x4a)[0x563d40133aca] pthread_create.c:0(start_thread)[0x7fd6f14bedd5] /lib64/libc.so.6(clone+0x6d)[0x7fd6efcb7ead] Trying to get some variables. Some pointers may be invalid and cause the dump to abort. Query (0x7fd6b0004c18): UPDATE `ipaddresses` SET `lastSeen`='2019-04-24 04:00:01' WHERE `id`='5956' Connection ID (thread ID): 12 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=on,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=off,table_elimination=on,extended_keys=off 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. 190424 04:00:13 mysqld_safe Number of processes running now: 0 190424 04:00:13 mysqld_safe mysqld restarted 190424 4:00:13 [Note] /usr/libexec/mysqld (mysqld 5.5.60-MariaDB) starting as process 13962 ... 190424 4:00:13 InnoDB: The InnoDB memory heap is disabled 190424 4:00:13 InnoDB: Mutexes and rw_locks use GCC atomic builtins 190424 4:00:13 InnoDB: Compressed tables use zlib 1.2.7 190424 4:00:13 InnoDB: Using Linux native AIO 190424 4:00:13 InnoDB: Initializing buffer pool, size = 128.0M 190424 4:00:13 InnoDB: Completed initialization of buffer pool 190424 4:00:13 InnoDB: highest supported file format is Barracuda. 190424 4:00:13 InnoDB: Starting crash recovery from checkpoint LSN=18524510 InnoDB: Restoring possible half-written data pages from the doublewrite buffer... 190424 4:00:13 InnoDB: Starting final batch to recover 3 pages from redo log 190424 4:00:13 InnoDB: Waiting for the background threads to start 190424 4:00:14 Percona XtraDB (http://www.percona.com) 5.5.59-MariaDB-38.11 started; log sequence number 18558084 190424 4:00:14 [Note] Plugin 'FEEDBACK' is disabled. 190424 4:00:15 [Note] Server socket created on IP: '0.0.0.0'. 190424 4:00:15 [Note] Event Scheduler: Loaded 0 events 190424 4:00:15 [Note] /usr/libexec/mysqld: ready for connections. Version: '5.5.60-MariaDB' socket: '/data/mysql/mysql.sock' port: 3306 MariaDB Server 190424 4:15:13 InnoDB: Assertion failure in thread 139926681822976 in file fut0lst.ic line 83 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: http://dev.mysql.com/doc/refman/5.5/en/forcing-innodb-recovery.html InnoDB: about forcing recovery. 190424 4:15:13 [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 http://kb.askmonty.org/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: 5.5.60-MariaDB key_buffer_size=134217728 read_buffer_size=131072 max_used_connections=4 max_threads=153 thread_count=1 It is possible that mysqld could use up to key_buffer_size + (read_buffer_size + sort_buffer_size)*max_threads = 466718 K bytes of memory Hope that's ok; if not, decrease some variables in the equation. Thread pointer: 0x5646eef32930 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 = 0x7f43382a1d80 thread_stack 0x48000 /usr/libexec/mysqld(my_print_stacktrace+0x3d)[0x5646ed4f1cbd] /usr/libexec/mysqld(handle_fatal_signal+0x515)[0x5646ed1064a5] sigaction.c:0(__restore_rt)[0x7f433c9a95d0] :0(__GI_raise)[0x7f433b0d3207] :0(__GI_abort)[0x7f433b0d48f8] /usr/libexec/mysqld(+0x2d73b7)[0x5646ecf393b7] /usr/libexec/mysqld(+0x6f87d0)[0x5646ed35a7d0] /usr/libexec/mysqld(+0x657ade)[0x5646ed2b9ade] /usr/libexec/mysqld(+0x671153)[0x5646ed2d3153] /usr/libexec/mysqld(+0x666faf)[0x5646ed2c8faf] /usr/libexec/mysqld(+0x668d94)[0x5646ed2cad94] /usr/libexec/mysqld(+0x66a6c7)[0x5646ed2cc6c7] /usr/libexec/mysqld(+0x60a5a0)[0x5646ed26c5a0] /usr/libexec/mysqld(+0x60b54b)[0x5646ed26d54b] /usr/libexec/mysqld(_Z19ha_commit_one_phaseP3THDb+0x80)[0x5646ed108ac0] /usr/libexec/mysqld(_Z15ha_commit_transP3THDb+0x356)[0x5646ed109236] /usr/libexec/mysqld(_Z17trans_commit_stmtP3THD+0x1b)[0x5646ed09c3bb] /usr/libexec/mysqld(_Z21mysql_execute_commandP3THD+0x3dc)[0x5646ecfd49ec] /usr/libexec/mysqld(_Z11mysql_parseP3THDPcjP12Parser_state+0x125)[0x5646ecfdb445] /usr/libexec/mysqld(_Z16dispatch_command19enum_server_commandP3THDPcj+0x1750)[0x5646ecfdd4a0] /usr/libexec/mysqld(_Z24do_handle_one_connectionP3THD+0x1c2)[0x5646ed08fa22] /usr/libexec/mysqld(handle_one_connection+0x4a)[0x5646ed08faca] pthread_create.c:0(start_thread)[0x7f433c9a1dd5] /lib64/libc.so.6(clone+0x6d)[0x7f433b19aead] Trying to get some variables. Some pointers may be invalid and cause the dump to abort. Query (0x7f42f4004c18): UPDATE `ipaddresses` SET `lastSeen`='2019-04-24 04:15:01' WHERE `id`='5956' Connection ID (thread ID): 12 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=on,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=off,table_elimination=on,extended_keys=off 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. 190424 04:15:14 mysqld_safe Number of processes running now: 0 190424 04:15:14 mysqld_safe mysqld restarted 190424 4:15:14 [Note] /usr/libexec/mysqld (mysqld 5.5.60-MariaDB) starting as process 15480 ... 190424 4:15:14 InnoDB: The InnoDB memory heap is disabled 190424 4:15:14 InnoDB: Mutexes and rw_locks use GCC atomic builtins 190424 4:15:14 InnoDB: Compressed tables use zlib 1.2.7 190424 4:15:14 InnoDB: Using Linux native AIO 190424 4:15:14 InnoDB: Initializing buffer pool, size = 128.0M 190424 4:15:14 InnoDB: Completed initialization of buffer pool 190424 4:15:14 InnoDB: highest supported file format is Barracuda. 190424 4:15:14 InnoDB: Starting crash recovery from checkpoint LSN=18564401 InnoDB: Restoring possible half-written data pages from the doublewrite buffer... 190424 4:15:14 InnoDB: Starting final batch to recover 3 pages from redo log 190424 4:15:14 InnoDB: Waiting for the background threads to start 190424 4:15:15 Percona XtraDB (http://www.percona.com) 5.5.59-MariaDB-38.11 started; log sequence number 18595634 190424 4:15:15 [Note] Plugin 'FEEDBACK' is disabled. 190424 4:15:15 [Note] Server socket created on IP: '0.0.0.0'. 190424 4:15:15 [Note] Event Scheduler: Loaded 0 events 190424 4:15:15 [Note] /usr/libexec/mysqld: ready for connections. Version: '5.5.60-MariaDB' socket: '/data/mysql/mysql.sock' port: 3306 MariaDB Server 190424 4:30:13 InnoDB: Assertion failure in thread 140276186986240 in file fut0lst.ic line 83 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: http://dev.mysql.com/doc/refman/5.5/en/forcing-innodb-recovery.html InnoDB: about forcing recovery. 190424 4:30:13 [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 http://kb.askmonty.org/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: 5.5.60-MariaDB key_buffer_size=134217728 read_buffer_size=131072 max_used_connections=3 max_threads=153 thread_count=1 It is possible that mysqld could use up to key_buffer_size + (read_buffer_size + sort_buffer_size)*max_threads = 466718 K bytes of memory Hope that's ok; if not, decrease some variables in the equation. Thread pointer: 0x55d6de23d8f0 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 = 0x7f94984bad80 thread_stack 0x48000 /usr/libexec/mysqld(my_print_stacktrace+0x3d)[0x55d6dc7fdcbd] /usr/libexec/mysqld(handle_fatal_signal+0x515)[0x55d6dc4124a5] sigaction.c:0(__restore_rt)[0x7f949f31c5d0] :0(__GI_raise)[0x7f949da46207] :0(__GI_abort)[0x7f949da478f8] /usr/libexec/mysqld(+0x2d73b7)[0x55d6dc2453b7] /usr/libexec/mysqld(+0x6f87d0)[0x55d6dc6667d0] /usr/libexec/mysqld(+0x657ade)[0x55d6dc5c5ade] /usr/libexec/mysqld(+0x671153)[0x55d6dc5df153] /usr/libexec/mysqld(+0x666faf)[0x55d6dc5d4faf] /usr/libexec/mysqld(+0x668d94)[0x55d6dc5d6d94] /usr/libexec/mysqld(+0x66a6c7)[0x55d6dc5d86c7] /usr/libexec/mysqld(+0x60a5a0)[0x55d6dc5785a0] /usr/libexec/mysqld(+0x60b54b)[0x55d6dc57954b] /usr/libexec/mysqld(_Z19ha_commit_one_phaseP3THDb+0x80)[0x55d6dc414ac0] /usr/libexec/mysqld(_Z15ha_commit_transP3THDb+0x356)[0x55d6dc415236] /usr/libexec/mysqld(_Z17trans_commit_stmtP3THD+0x1b)[0x55d6dc3a83bb] /usr/libexec/mysqld(_Z21mysql_execute_commandP3THD+0x3dc)[0x55d6dc2e09ec] /usr/libexec/mysqld(_Z11mysql_parseP3THDPcjP12Parser_state+0x125)[0x55d6dc2e7445] /usr/libexec/mysqld(_Z16dispatch_command19enum_server_commandP3THDPcj+0x1750)[0x55d6dc2e94a0] /usr/libexec/mysqld(_Z24do_handle_one_connectionP3THD+0x1c2)[0x55d6dc39ba22] /usr/libexec/mysqld(handle_one_connection+0x4a)[0x55d6dc39baca] pthread_create.c:0(start_thread)[0x7f949f314dd5] /lib64/libc.so.6(clone+0x6d)[0x7f949db0dead] Trying to get some variables. Some pointers may be invalid and cause the dump to abort. Query (0x7f9458004c18): UPDATE `ipaddresses` SET `lastSeen`='2019-04-24 04:30:01' WHERE `id`='5956' Connection ID (thread ID): 12 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=on,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=off,table_elimination=on,extended_keys=off 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. 190424 04:30:13 mysqld_safe Number of processes running now: 0 190424 04:30:13 mysqld_safe mysqld restarted 190424 4:30:13 [Note] /usr/libexec/mysqld (mysqld 5.5.60-MariaDB) starting as process 17479 ... 190424 4:30:13 InnoDB: The InnoDB memory heap is disabled 190424 4:30:13 InnoDB: Mutexes and rw_locks use GCC atomic builtins 190424 4:30:13 InnoDB: Compressed tables use zlib 1.2.7 190424 4:30:13 InnoDB: Using Linux native AIO 190424 4:30:13 InnoDB: Initializing buffer pool, size = 128.0M 190424 4:30:13 InnoDB: Completed initialization of buffer pool 190424 4:30:13 InnoDB: highest supported file format is Barracuda. 190424 4:30:13 InnoDB: Starting crash recovery from checkpoint LSN=18601634 InnoDB: Restoring possible half-written data pages from the doublewrite buffer... 190424 4:30:13 InnoDB: Starting final batch to recover 3 pages from redo log 190424 4:30:14 InnoDB: Waiting for the background threads to start 190424 4:30:15 Percona XtraDB (http://www.percona.com) 5.5.59-MariaDB-38.11 started; log sequence number 18632849 190424 4:30:15 [Note] Plugin 'FEEDBACK' is disabled. 190424 4:30:15 [Note] Server socket created on IP: '0.0.0.0'. 190424 4:30:15 [Note] Event Scheduler: Loaded 0 events 190424 4:30:15 [Note] /usr/libexec/mysqld: ready for connections. Version: '5.5.60-MariaDB' socket: '/data/mysql/mysql.sock' port: 3306 MariaDB Server 190424 4:45:13 InnoDB: Assertion failure in thread 139972250859264 in file fut0lst.ic line 83 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: http://dev.mysql.com/doc/refman/5.5/en/forcing-innodb-recovery.html InnoDB: about forcing recovery. 190424 4:45:13 [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 http://kb.askmonty.org/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: 5.5.60-MariaDB key_buffer_size=134217728 read_buffer_size=131072 max_used_connections=3 max_threads=153 thread_count=1 It is possible that mysqld could use up to key_buffer_size + (read_buffer_size + sort_buffer_size)*max_threads = 466718 K bytes of memory Hope that's ok; if not, decrease some variables in the equation. Thread pointer: 0x5641b236fab0 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 = 0x7f4dd44a6d80 thread_stack 0x48000 /usr/libexec/mysqld(my_print_stacktrace+0x3d)[0x5641aed6ecbd] /usr/libexec/mysqld(handle_fatal_signal+0x515)[0x5641ae9834a5] sigaction.c:0(__restore_rt)[0x7f4ddb3085d0] :0(__GI_raise)[0x7f4dd9a32207] :0(__GI_abort)[0x7f4dd9a338f8] /usr/libexec/mysqld(+0x2d73b7)[0x5641ae7b63b7] /usr/libexec/mysqld(+0x6f87d0)[0x5641aebd77d0] /usr/libexec/mysqld(+0x657ade)[0x5641aeb36ade] /usr/libexec/mysqld(+0x671153)[0x5641aeb50153] /usr/libexec/mysqld(+0x666faf)[0x5641aeb45faf] /usr/libexec/mysqld(+0x668d94)[0x5641aeb47d94] /usr/libexec/mysqld(+0x66a6c7)[0x5641aeb496c7] /usr/libexec/mysqld(+0x60a5a0)[0x5641aeae95a0] /usr/libexec/mysqld(+0x60b54b)[0x5641aeaea54b] /usr/libexec/mysqld(_Z19ha_commit_one_phaseP3THDb+0x80)[0x5641ae985ac0] /usr/libexec/mysqld(_Z15ha_commit_transP3THDb+0x356)[0x5641ae986236] /usr/libexec/mysqld(_Z17trans_commit_stmtP3THD+0x1b)[0x5641ae9193bb] /usr/libexec/mysqld(_Z21mysql_execute_commandP3THD+0x3dc)[0x5641ae8519ec] /usr/libexec/mysqld(_Z11mysql_parseP3THDPcjP12Parser_state+0x125)[0x5641ae858445] /usr/libexec/mysqld(_Z16dispatch_command19enum_server_commandP3THDPcj+0x1750)[0x5641ae85a4a0] /usr/libexec/mysqld(_Z24do_handle_one_connectionP3THD+0x1c2)[0x5641ae90ca22] /usr/libexec/mysqld(handle_one_connection+0x4a)[0x5641ae90caca] pthread_create.c:0(start_thread)[0x7f4ddb300dd5] /lib64/libc.so.6(clone+0x6d)[0x7f4dd9af9ead] Trying to get some variables. Some pointers may be invalid and cause the dump to abort. Query (0x7f4d94004c18): UPDATE `ipaddresses` SET `lastSeen`='2019-04-24 04:45:01' WHERE `id`='5956' Connection ID (thread ID): 12 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=on,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=off,table_elimination=on,extended_keys=off 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. 190424 04:45:13 mysqld_safe Number of processes running now: 0 190424 04:45:13 mysqld_safe mysqld restarted 190424 4:45:13 [Note] /usr/libexec/mysqld (mysqld 5.5.60-MariaDB) starting as process 18988 ... 190424 4:45:13 InnoDB: The InnoDB memory heap is disabled 190424 4:45:13 InnoDB: Mutexes and rw_locks use GCC atomic builtins 190424 4:45:13 InnoDB: Compressed tables use zlib 1.2.7 190424 4:45:13 InnoDB: Using Linux native AIO 190424 4:45:13 InnoDB: Initializing buffer pool, size = 128.0M 190424 4:45:14 InnoDB: Completed initialization of buffer pool 190424 4:45:14 InnoDB: highest supported file format is Barracuda. 190424 4:45:14 InnoDB: Starting crash recovery from checkpoint LSN=18638727 InnoDB: Restoring possible half-written data pages from the doublewrite buffer... 190424 4:45:14 InnoDB: Starting final batch to recover 2 pages from redo log 190424 4:45:14 InnoDB: Waiting for the background threads to start 190424 4:45:15 Percona XtraDB (http://www.percona.com) 5.5.59-MariaDB-38.11 started; log sequence number 18669211 190424 4:45:15 [Note] Plugin 'FEEDBACK' is disabled. 190424 4:45:15 [Note] Server socket created on IP: '0.0.0.0'. 190424 4:45:15 [Note] Event Scheduler: Loaded 0 events 190424 4:45:15 [Note] /usr/libexec/mysqld: ready for connections. Version: '5.5.60-MariaDB' socket: '/data/mysql/mysql.sock' port: 3306 MariaDB Server 190424 5:00:14 InnoDB: Assertion failure in thread 140191759513344 in file fut0lst.ic line 83 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: http://dev.mysql.com/doc/refman/5.5/en/forcing-innodb-recovery.html InnoDB: about forcing recovery. 190424 5:00:14 [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 http://kb.askmonty.org/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: 5.5.60-MariaDB key_buffer_size=134217728 read_buffer_size=131072 max_used_connections=3 max_threads=153 thread_count=1 It is possible that mysqld could use up to key_buffer_size + (read_buffer_size + sort_buffer_size)*max_threads = 466718 K bytes of memory Hope that's ok; if not, decrease some variables in the equation. Thread pointer: 0x555827f01ab0 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 = 0x7f80f006ad80 thread_stack 0x48000 /usr/libexec/mysqld(my_print_stacktrace+0x3d)[0x55582464acbd] /usr/libexec/mysqld(handle_fatal_signal+0x515)[0x55582425f4a5] sigaction.c:0(__restore_rt)[0x7f80f5d3f5d0] :0(__GI_raise)[0x7f80f4469207] :0(__GI_abort)[0x7f80f446a8f8] /usr/libexec/mysqld(+0x2d73b7)[0x5558240923b7] /usr/libexec/mysqld(+0x6f87d0)[0x5558244b37d0] /usr/libexec/mysqld(+0x657ade)[0x555824412ade] /usr/libexec/mysqld(+0x671153)[0x55582442c153] /usr/libexec/mysqld(+0x666faf)[0x555824421faf] /usr/libexec/mysqld(+0x668d94)[0x555824423d94] /usr/libexec/mysqld(+0x66a6c7)[0x5558244256c7] /usr/libexec/mysqld(+0x60a5a0)[0x5558243c55a0] /usr/libexec/mysqld(+0x60b54b)[0x5558243c654b] /usr/libexec/mysqld(_Z19ha_commit_one_phaseP3THDb+0x80)[0x555824261ac0] /usr/libexec/mysqld(_Z15ha_commit_transP3THDb+0x356)[0x555824262236] /usr/libexec/mysqld(_Z17trans_commit_stmtP3THD+0x1b)[0x5558241f53bb] /usr/libexec/mysqld(_Z21mysql_execute_commandP3THD+0x3dc)[0x55582412d9ec] /usr/libexec/mysqld(_Z11mysql_parseP3THDPcjP12Parser_state+0x125)[0x555824134445] /usr/libexec/mysqld(_Z16dispatch_command19enum_server_commandP3THDPcj+0x1750)[0x5558241364a0] /usr/libexec/mysqld(_Z24do_handle_one_connectionP3THD+0x1c2)[0x5558241e8a22] /usr/libexec/mysqld(handle_one_connection+0x4a)[0x5558241e8aca] pthread_create.c:0(start_thread)[0x7f80f5d37dd5] /lib64/libc.so.6(clone+0x6d)[0x7f80f4530ead] Trying to get some variables. Some pointers may be invalid and cause the dump to abort. Query (0x7f80b0004c18): UPDATE `ipaddresses` SET `lastSeen`='2019-04-24 05:00:02' WHERE `id`='5956' Connection ID (thread ID): 12 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=on,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=off,table_elimination=on,extended_keys=off 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. 190424 05:00:14 mysqld_safe Number of processes running now: 0 190424 05:00:14 mysqld_safe mysqld restarted 190424 5:00:14 [Note] /usr/libexec/mysqld (mysqld 5.5.60-MariaDB) starting as process 20969 ... 190424 5:00:14 InnoDB: The InnoDB memory heap is disabled 190424 5:00:14 InnoDB: Mutexes and rw_locks use GCC atomic builtins 190424 5:00:14 InnoDB: Compressed tables use zlib 1.2.7 190424 5:00:14 InnoDB: Using Linux native AIO 190424 5:00:14 InnoDB: Initializing buffer pool, size = 128.0M 190424 5:00:14 InnoDB: Completed initialization of buffer pool 190424 5:00:14 InnoDB: highest supported file format is Barracuda. 190424 5:00:14 InnoDB: Starting crash recovery from checkpoint LSN=18675089 InnoDB: Restoring possible half-written data pages from the doublewrite buffer... 190424 5:00:14 InnoDB: Starting final batch to recover 2 pages from redo log 190424 5:00:15 InnoDB: Waiting for the background threads to start 190424 5:00:16 Percona XtraDB (http://www.percona.com) 5.5.59-MariaDB-38.11 started; log sequence number 18705574 190424 5:00:16 [Note] Plugin 'FEEDBACK' is disabled. 190424 5:00:16 [Note] Server socket created on IP: '0.0.0.0'. 190424 5:00:16 [Note] Event Scheduler: Loaded 0 events 190424 5:00:16 [Note] /usr/libexec/mysqld: ready for connections. Version: '5.5.60-MariaDB' socket: '/data/mysql/mysql.sock' port: 3306 MariaDB Server 190424 5:15:13 InnoDB: Assertion failure in thread 139939367753472 in file fut0lst.ic line 83 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: http://dev.mysql.com/doc/refman/5.5/en/forcing-innodb-recovery.html InnoDB: about forcing recovery. 190424 5:15:13 [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 http://kb.askmonty.org/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: 5.5.60-MariaDB key_buffer_size=134217728 read_buffer_size=131072 max_used_connections=3 max_threads=153 thread_count=1 It is possible that mysqld could use up to key_buffer_size + (read_buffer_size + sort_buffer_size)*max_threads = 466718 K bytes of memory Hope that's ok; if not, decrease some variables in the equation. Thread pointer: 0x559666314ab0 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 = 0x7f462c4e0d80 thread_stack 0x48000 /usr/libexec/mysqld(my_print_stacktrace+0x3d)[0x559663c80cbd] /usr/libexec/mysqld(handle_fatal_signal+0x515)[0x5596638954a5] sigaction.c:0(__restore_rt)[0x7f46303e75d0] :0(__GI_raise)[0x7f462eb11207] :0(__GI_abort)[0x7f462eb128f8] /usr/libexec/mysqld(+0x2d73b7)[0x5596636c83b7] /usr/libexec/mysqld(+0x6f87d0)[0x559663ae97d0] /usr/libexec/mysqld(+0x657ade)[0x559663a48ade] /usr/libexec/mysqld(+0x671153)[0x559663a62153] /usr/libexec/mysqld(+0x666faf)[0x559663a57faf] /usr/libexec/mysqld(+0x668d94)[0x559663a59d94] /usr/libexec/mysqld(+0x66a6c7)[0x559663a5b6c7] /usr/libexec/mysqld(+0x60a5a0)[0x5596639fb5a0] /usr/libexec/mysqld(+0x60b54b)[0x5596639fc54b] /usr/libexec/mysqld(_Z19ha_commit_one_phaseP3THDb+0x80)[0x559663897ac0] /usr/libexec/mysqld(_Z15ha_commit_transP3THDb+0x356)[0x559663898236] /usr/libexec/mysqld(_Z17trans_commit_stmtP3THD+0x1b)[0x55966382b3bb] /usr/libexec/mysqld(_Z21mysql_execute_commandP3THD+0x3dc)[0x5596637639ec] /usr/libexec/mysqld(_Z11mysql_parseP3THDPcjP12Parser_state+0x125)[0x55966376a445] /usr/libexec/mysqld(_Z16dispatch_command19enum_server_commandP3THDPcj+0x1750)[0x55966376c4a0] /usr/libexec/mysqld(_Z24do_handle_one_connectionP3THD+0x1c2)[0x55966381ea22] /usr/libexec/mysqld(handle_one_connection+0x4a)[0x55966381eaca] pthread_create.c:0(start_thread)[0x7f46303dfdd5] /lib64/libc.so.6(clone+0x6d)[0x7f462ebd8ead] Trying to get some variables. Some pointers may be invalid and cause the dump to abort. Query (0x7f45e8004c18): UPDATE `ipaddresses` SET `lastSeen`='2019-04-24 05:15:01' WHERE `id`='5956' Connection ID (thread ID): 12 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=on,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=off,table_elimination=on,extended_keys=off 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. 190424 05:15:13 mysqld_safe Number of processes running now: 0 190424 05:15:13 mysqld_safe mysqld restarted 190424 5:15:13 [Note] /usr/libexec/mysqld (mysqld 5.5.60-MariaDB) starting as process 22492 ... 190424 5:15:13 InnoDB: The InnoDB memory heap is disabled 190424 5:15:13 InnoDB: Mutexes and rw_locks use GCC atomic builtins 190424 5:15:13 InnoDB: Compressed tables use zlib 1.2.7 190424 5:15:13 InnoDB: Using Linux native AIO 190424 5:15:13 InnoDB: Initializing buffer pool, size = 128.0M 190424 5:15:13 InnoDB: Completed initialization of buffer pool 190424 5:15:13 InnoDB: highest supported file format is Barracuda. 190424 5:15:13 InnoDB: Starting crash recovery from checkpoint LSN=18711452 InnoDB: Restoring possible half-written data pages from the doublewrite buffer... 190424 5:15:13 InnoDB: Starting final batch to recover 2 pages from redo log 190424 5:15:14 InnoDB: Waiting for the background threads to start 190424 5:15:15 Percona XtraDB (http://www.percona.com) 5.5.59-MariaDB-38.11 started; log sequence number 18741937 190424 5:15:15 [Note] Plugin 'FEEDBACK' is disabled. 190424 5:15:15 [Note] Server socket created on IP: '0.0.0.0'. 190424 5:15:15 [Note] Event Scheduler: Loaded 0 events 190424 5:15:15 [Note] /usr/libexec/mysqld: ready for connections. Version: '5.5.60-MariaDB' socket: '/data/mysql/mysql.sock' port: 3306 MariaDB Server 190424 5:30:14 InnoDB: Assertion failure in thread 140100288808704 in file fut0lst.ic line 83 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: http://dev.mysql.com/doc/refman/5.5/en/forcing-innodb-recovery.html InnoDB: about forcing recovery. 190424 5:30:14 [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 http://kb.askmonty.org/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: 5.5.60-MariaDB key_buffer_size=134217728 read_buffer_size=131072 max_used_connections=3 max_threads=153 thread_count=1 It is possible that mysqld could use up to key_buffer_size + (read_buffer_size + sort_buffer_size)*max_threads = 466718 K bytes of memory Hope that's ok; if not, decrease some variables in the equation. Thread pointer: 0x563872d0aab0 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 = 0x7f6ba3f27d80 thread_stack 0x48000 /usr/libexec/mysqld(my_print_stacktrace+0x3d)[0x56387076dcbd] /usr/libexec/mysqld(handle_fatal_signal+0x515)[0x5638703824a5] sigaction.c:0(__restore_rt)[0x7f6bc12265d0] :0(__GI_raise)[0x7f6bbf950207] :0(__GI_abort)[0x7f6bbf9518f8] /usr/libexec/mysqld(+0x2d73b7)[0x5638701b53b7] /usr/libexec/mysqld(+0x6f87d0)[0x5638705d67d0] /usr/libexec/mysqld(+0x657ade)[0x563870535ade] /usr/libexec/mysqld(+0x671153)[0x56387054f153] /usr/libexec/mysqld(+0x666faf)[0x563870544faf] /usr/libexec/mysqld(+0x668d94)[0x563870546d94] /usr/libexec/mysqld(+0x66a6c7)[0x5638705486c7] /usr/libexec/mysqld(+0x60a5a0)[0x5638704e85a0] /usr/libexec/mysqld(+0x60b54b)[0x5638704e954b] /usr/libexec/mysqld(_Z19ha_commit_one_phaseP3THDb+0x80)[0x563870384ac0] /usr/libexec/mysqld(_Z15ha_commit_transP3THDb+0x356)[0x563870385236] /usr/libexec/mysqld(_Z17trans_commit_stmtP3THD+0x1b)[0x5638703183bb] /usr/libexec/mysqld(_Z21mysql_execute_commandP3THD+0x3dc)[0x5638702509ec] /usr/libexec/mysqld(_Z11mysql_parseP3THDPcjP12Parser_state+0x125)[0x563870257445] /usr/libexec/mysqld(_Z16dispatch_command19enum_server_commandP3THDPcj+0x1750)[0x5638702594a0] /usr/libexec/mysqld(_Z24do_handle_one_connectionP3THD+0x1c2)[0x56387030ba22] /usr/libexec/mysqld(handle_one_connection+0x4a)[0x56387030baca] pthread_create.c:0(start_thread)[0x7f6bc121edd5] /lib64/libc.so.6(clone+0x6d)[0x7f6bbfa17ead] Trying to get some variables. Some pointers may be invalid and cause the dump to abort. Query (0x7f6b78004c18): UPDATE `ipaddresses` SET `lastSeen`='2019-04-24 05:30:01' WHERE `id`='5956' Connection ID (thread ID): 12 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=on,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=off,table_elimination=on,extended_keys=off 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. 190424 05:30:14 mysqld_safe Number of processes running now: 0 190424 05:30:14 mysqld_safe mysqld restarted 190424 5:30:15 [Note] /usr/libexec/mysqld (mysqld 5.5.60-MariaDB) starting as process 24478 ... 190424 5:30:15 InnoDB: The InnoDB memory heap is disabled 190424 5:30:15 InnoDB: Mutexes and rw_locks use GCC atomic builtins 190424 5:30:15 InnoDB: Compressed tables use zlib 1.2.7 190424 5:30:15 InnoDB: Using Linux native AIO 190424 5:30:15 InnoDB: Initializing buffer pool, size = 128.0M 190424 5:30:15 InnoDB: Completed initialization of buffer pool 190424 5:30:15 InnoDB: highest supported file format is Barracuda. 190424 5:30:15 InnoDB: Starting crash recovery from checkpoint LSN=18747815 InnoDB: Restoring possible half-written data pages from the doublewrite buffer... 190424 5:30:15 InnoDB: Starting final batch to recover 2 pages from redo log 190424 5:30:15 InnoDB: Waiting for the background threads to start 190424 5:30:16 Percona XtraDB (http://www.percona.com) 5.5.59-MariaDB-38.11 started; log sequence number 18778300 190424 5:30:16 [Note] Plugin 'FEEDBACK' is disabled. 190424 5:30:16 [Note] Server socket created on IP: '0.0.0.0'. 190424 5:30:16 [Note] Event Scheduler: Loaded 0 events 190424 5:30:16 [Note] /usr/libexec/mysqld: ready for connections. Version: '5.5.60-MariaDB' socket: '/data/mysql/mysql.sock' port: 3306 MariaDB Server 190424 5:45:13 InnoDB: Assertion failure in thread 140114655737600 in file fut0lst.ic line 83 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: http://dev.mysql.com/doc/refman/5.5/en/forcing-innodb-recovery.html InnoDB: about forcing recovery. 190424 5:45:13 [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 http://kb.askmonty.org/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: 5.5.60-MariaDB key_buffer_size=134217728 read_buffer_size=131072 max_used_connections=3 max_threads=153 thread_count=1 It is possible that mysqld could use up to key_buffer_size + (read_buffer_size + sort_buffer_size)*max_threads = 466718 K bytes of memory Hope that's ok; if not, decrease some variables in the equation. Thread pointer: 0x563b14189ab0 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 = 0x7f6efc486d80 thread_stack 0x48000 /usr/libexec/mysqld(my_print_stacktrace+0x3d)[0x563b10d3fcbd] /usr/libexec/mysqld(handle_fatal_signal+0x515)[0x563b109544a5] sigaction.c:0(__restore_rt)[0x7f6f022e65d0] :0(__GI_raise)[0x7f6f00a10207] :0(__GI_abort)[0x7f6f00a118f8] /usr/libexec/mysqld(+0x2d73b7)[0x563b107873b7] /usr/libexec/mysqld(+0x6f87d0)[0x563b10ba87d0] /usr/libexec/mysqld(+0x657ade)[0x563b10b07ade] /usr/libexec/mysqld(+0x671153)[0x563b10b21153] /usr/libexec/mysqld(+0x666faf)[0x563b10b16faf] /usr/libexec/mysqld(+0x668d94)[0x563b10b18d94] /usr/libexec/mysqld(+0x66a6c7)[0x563b10b1a6c7] /usr/libexec/mysqld(+0x60a5a0)[0x563b10aba5a0] /usr/libexec/mysqld(+0x60b54b)[0x563b10abb54b] /usr/libexec/mysqld(_Z19ha_commit_one_phaseP3THDb+0x80)[0x563b10956ac0] /usr/libexec/mysqld(_Z15ha_commit_transP3THDb+0x356)[0x563b10957236] /usr/libexec/mysqld(_Z17trans_commit_stmtP3THD+0x1b)[0x563b108ea3bb] /usr/libexec/mysqld(_Z21mysql_execute_commandP3THD+0x3dc)[0x563b108229ec] /usr/libexec/mysqld(_Z11mysql_parseP3THDPcjP12Parser_state+0x125)[0x563b10829445] /usr/libexec/mysqld(_Z16dispatch_command19enum_server_commandP3THDPcj+0x1750)[0x563b1082b4a0] /usr/libexec/mysqld(_Z24do_handle_one_connectionP3THD+0x1c2)[0x563b108dda22] /usr/libexec/mysqld(handle_one_connection+0x4a)[0x563b108ddaca] pthread_create.c:0(start_thread)[0x7f6f022dedd5] /lib64/libc.so.6(clone+0x6d)[0x7f6f00ad7ead] Trying to get some variables. Some pointers may be invalid and cause the dump to abort. Query (0x7f6ebc004c18): UPDATE `ipaddresses` SET `lastSeen`='2019-04-24 05:45:02' WHERE `id`='5956' Connection ID (thread ID): 12 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=on,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=off,table_elimination=on,extended_keys=off 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. 190424 05:45:13 mysqld_safe Number of processes running now: 0 190424 05:45:13 mysqld_safe mysqld restarted 190424 5:45:14 [Note] /usr/libexec/mysqld (mysqld 5.5.60-MariaDB) starting as process 26044 ... 190424 5:45:14 InnoDB: The InnoDB memory heap is disabled 190424 5:45:14 InnoDB: Mutexes and rw_locks use GCC atomic builtins 190424 5:45:14 InnoDB: Compressed tables use zlib 1.2.7 190424 5:45:14 InnoDB: Using Linux native AIO 190424 5:45:14 InnoDB: Initializing buffer pool, size = 128.0M 190424 5:45:14 InnoDB: Completed initialization of buffer pool 190424 5:45:14 InnoDB: highest supported file format is Barracuda. 190424 5:45:14 InnoDB: Starting crash recovery from checkpoint LSN=18784196 InnoDB: Restoring possible half-written data pages from the doublewrite buffer... 190424 5:45:14 InnoDB: Starting final batch to recover 2 pages from redo log 190424 5:45:14 InnoDB: Waiting for the background threads to start 190424 5:45:15 Percona XtraDB (http://www.percona.com) 5.5.59-MariaDB-38.11 started; log sequence number 18814681 190424 5:45:15 [Note] Plugin 'FEEDBACK' is disabled. 190424 5:45:15 [Note] Server socket created on IP: '0.0.0.0'. 190424 5:45:15 [Note] Event Scheduler: Loaded 0 events 190424 5:45:15 [Note] /usr/libexec/mysqld: ready for connections. Version: '5.5.60-MariaDB' socket: '/data/mysql/mysql.sock' port: 3306 MariaDB Server 190424 6:00:13 InnoDB: Assertion failure in thread 140200285452032 in file fut0lst.ic line 83 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: http://dev.mysql.com/doc/refman/5.5/en/forcing-innodb-recovery.html InnoDB: about forcing recovery. 190424 6:00:13 [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 http://kb.askmonty.org/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: 5.5.60-MariaDB key_buffer_size=134217728 read_buffer_size=131072 max_used_connections=3 max_threads=153 thread_count=1 It is possible that mysqld could use up to key_buffer_size + (read_buffer_size + sort_buffer_size)*max_threads = 466718 K bytes of memory Hope that's ok; if not, decrease some variables in the equation. Thread pointer: 0x55fd0a1298f0 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 = 0x7f82ec362d80 thread_stack 0x48000 /usr/libexec/mysqld(my_print_stacktrace+0x3d)[0x55fd06b6ccbd] /usr/libexec/mysqld(handle_fatal_signal+0x515)[0x55fd067814a5] sigaction.c:0(__restore_rt)[0x7f82f17ae5d0] :0(__GI_raise)[0x7f82efed8207] :0(__GI_abort)[0x7f82efed98f8] /usr/libexec/mysqld(+0x2d73b7)[0x55fd065b43b7] /usr/libexec/mysqld(+0x6f87d0)[0x55fd069d57d0] /usr/libexec/mysqld(+0x657ade)[0x55fd06934ade] /usr/libexec/mysqld(+0x671153)[0x55fd0694e153] /usr/libexec/mysqld(+0x666faf)[0x55fd06943faf] /usr/libexec/mysqld(+0x668d94)[0x55fd06945d94] /usr/libexec/mysqld(+0x66a6c7)[0x55fd069476c7] /usr/libexec/mysqld(+0x60a5a0)[0x55fd068e75a0] /usr/libexec/mysqld(+0x60b54b)[0x55fd068e854b] /usr/libexec/mysqld(_Z19ha_commit_one_phaseP3THDb+0x80)[0x55fd06783ac0] /usr/libexec/mysqld(_Z15ha_commit_transP3THDb+0x356)[0x55fd06784236] /usr/libexec/mysqld(_Z17trans_commit_stmtP3THD+0x1b)[0x55fd067173bb] /usr/libexec/mysqld(_Z21mysql_execute_commandP3THD+0x3dc)[0x55fd0664f9ec] /usr/libexec/mysqld(_Z11mysql_parseP3THDPcjP12Parser_state+0x125)[0x55fd06656445] /usr/libexec/mysqld(_Z16dispatch_command19enum_server_commandP3THDPcj+0x1750)[0x55fd066584a0] /usr/libexec/mysqld(_Z24do_handle_one_connectionP3THD+0x1c2)[0x55fd0670aa22] /usr/libexec/mysqld(handle_one_connection+0x4a)[0x55fd0670aaca] pthread_create.c:0(start_thread)[0x7f82f17a6dd5] /lib64/libc.so.6(clone+0x6d)[0x7f82eff9fead] Trying to get some variables. Some pointers may be invalid and cause the dump to abort. Query (0x7f82b0004c18): UPDATE `ipaddresses` SET `lastSeen`='2019-04-24 06:00:02' WHERE `id`='5956' Connection ID (thread ID): 12 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=on,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=off,table_elimination=on,extended_keys=off 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. 190424 06:00:13 mysqld_safe Number of processes running now: 0 190424 06:00:13 mysqld_safe mysqld restarted 190424 6:00:14 [Note] /usr/libexec/mysqld (mysqld 5.5.60-MariaDB) starting as process 28032 ... 190424 6:00:14 InnoDB: The InnoDB memory heap is disabled 190424 6:00:14 InnoDB: Mutexes and rw_locks use GCC atomic builtins 190424 6:00:14 InnoDB: Compressed tables use zlib 1.2.7 190424 6:00:14 InnoDB: Using Linux native AIO 190424 6:00:14 InnoDB: Initializing buffer pool, size = 128.0M 190424 6:00:14 InnoDB: Completed initialization of buffer pool 190424 6:00:14 InnoDB: highest supported file format is Barracuda. 190424 6:00:14 InnoDB: Starting crash recovery from checkpoint LSN=18821460 InnoDB: Restoring possible half-written data pages from the doublewrite buffer... 190424 6:00:14 InnoDB: Starting final batch to recover 2 pages from redo log 190424 6:00:14 InnoDB: Waiting for the background threads to start 190424 6:00:15 Percona XtraDB (http://www.percona.com) 5.5.59-MariaDB-38.11 started; log sequence number 18851945 190424 6:00:15 [Note] Plugin 'FEEDBACK' is disabled. 190424 6:00:15 [Note] Server socket created on IP: '0.0.0.0'. 190424 6:00:15 [Note] Event Scheduler: Loaded 0 events 190424 6:00:15 [Note] /usr/libexec/mysqld: ready for connections. Version: '5.5.60-MariaDB' socket: '/data/mysql/mysql.sock' port: 3306 MariaDB Server 190424 6:15:13 InnoDB: Assertion failure in thread 139884002539264 in file fut0lst.ic line 83 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: http://dev.mysql.com/doc/refman/5.5/en/forcing-innodb-recovery.html InnoDB: about forcing recovery. 190424 6:15:13 [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 http://kb.askmonty.org/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: 5.5.60-MariaDB key_buffer_size=134217728 read_buffer_size=131072 max_used_connections=3 max_threads=153 thread_count=1 It is possible that mysqld could use up to key_buffer_size + (read_buffer_size + sort_buffer_size)*max_threads = 466718 K bytes of memory Hope that's ok; if not, decrease some variables in the equation. Thread pointer: 0x5562e21abab0 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 = 0x7f394847ed80 thread_stack 0x48000 /usr/libexec/mysqld(my_print_stacktrace+0x3d)[0x5562df8b5cbd] /usr/libexec/mysqld(handle_fatal_signal+0x515)[0x5562df4ca4a5] sigaction.c:0(__restore_rt)[0x7f394c3855d0] :0(__GI_raise)[0x7f394aaaf207] :0(__GI_abort)[0x7f394aab08f8] /usr/libexec/mysqld(+0x2d73b7)[0x5562df2fd3b7] /usr/libexec/mysqld(+0x6f87d0)[0x5562df71e7d0] /usr/libexec/mysqld(+0x657ade)[0x5562df67dade] /usr/libexec/mysqld(+0x671153)[0x5562df697153] /usr/libexec/mysqld(+0x666faf)[0x5562df68cfaf] /usr/libexec/mysqld(+0x668d94)[0x5562df68ed94] /usr/libexec/mysqld(+0x66a6c7)[0x5562df6906c7] /usr/libexec/mysqld(+0x60a5a0)[0x5562df6305a0] /usr/libexec/mysqld(+0x60b54b)[0x5562df63154b] /usr/libexec/mysqld(_Z19ha_commit_one_phaseP3THDb+0x80)[0x5562df4ccac0] /usr/libexec/mysqld(_Z15ha_commit_transP3THDb+0x356)[0x5562df4cd236] /usr/libexec/mysqld(_Z17trans_commit_stmtP3THD+0x1b)[0x5562df4603bb] /usr/libexec/mysqld(_Z21mysql_execute_commandP3THD+0x3dc)[0x5562df3989ec] /usr/libexec/mysqld(_Z11mysql_parseP3THDPcjP12Parser_state+0x125)[0x5562df39f445] /usr/libexec/mysqld(_Z16dispatch_command19enum_server_commandP3THDPcj+0x1750)[0x5562df3a14a0] /usr/libexec/mysqld(_Z24do_handle_one_connectionP3THD+0x1c2)[0x5562df453a22] /usr/libexec/mysqld(handle_one_connection+0x4a)[0x5562df453aca] pthread_create.c:0(start_thread)[0x7f394c37ddd5] /lib64/libc.so.6(clone+0x6d)[0x7f394ab76ead] Trying to get some variables. Some pointers may be invalid and cause the dump to abort. Query (0x7f3904004c18): UPDATE `ipaddresses` SET `lastSeen`='2019-04-24 06:15:01' WHERE `id`='5956' Connection ID (thread ID): 12 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=on,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=off,table_elimination=on,extended_keys=off 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. 190424 06:15:13 mysqld_safe Number of processes running now: 0 190424 06:15:13 mysqld_safe mysqld restarted 190424 6:15:13 [Note] /usr/libexec/mysqld (mysqld 5.5.60-MariaDB) starting as process 29567 ... 190424 6:15:13 InnoDB: The InnoDB memory heap is disabled 190424 6:15:13 InnoDB: Mutexes and rw_locks use GCC atomic builtins 190424 6:15:13 InnoDB: Compressed tables use zlib 1.2.7 190424 6:15:13 InnoDB: Using Linux native AIO 190424 6:15:13 InnoDB: Initializing buffer pool, size = 128.0M 190424 6:15:13 InnoDB: Completed initialization of buffer pool 190424 6:15:13 InnoDB: highest supported file format is Barracuda. 190424 6:15:13 InnoDB: Starting crash recovery from checkpoint LSN=18857944 InnoDB: Restoring possible half-written data pages from the doublewrite buffer... 190424 6:15:13 InnoDB: Starting final batch to recover 3 pages from redo log 190424 6:15:13 InnoDB: Waiting for the background threads to start 190424 6:15:14 Percona XtraDB (http://www.percona.com) 5.5.59-MariaDB-38.11 started; log sequence number 18889160 190424 6:15:14 [Note] Plugin 'FEEDBACK' is disabled. 190424 6:15:14 [Note] Server socket created on IP: '0.0.0.0'. 190424 6:15:14 [Note] Event Scheduler: Loaded 0 events 190424 6:15:14 [Note] /usr/libexec/mysqld: ready for connections. Version: '5.5.60-MariaDB' socket: '/data/mysql/mysql.sock' port: 3306 MariaDB Server 190424 6:30:13 InnoDB: Assertion failure in thread 140660919396096 in file fut0lst.ic line 83 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: http://dev.mysql.com/doc/refman/5.5/en/forcing-innodb-recovery.html InnoDB: about forcing recovery. 190424 6:30:13 [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 http://kb.askmonty.org/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: 5.5.60-MariaDB key_buffer_size=134217728 read_buffer_size=131072 max_used_connections=3 max_threads=153 thread_count=1 It is possible that mysqld could use up to key_buffer_size + (read_buffer_size + sort_buffer_size)*max_threads = 466718 K bytes of memory Hope that's ok; if not, decrease some variables in the equation. Thread pointer: 0x556bed9acab0 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 = 0x7fee2c225d80 thread_stack 0x48000 /usr/libexec/mysqld(my_print_stacktrace+0x3d)[0x556bea940cbd] /usr/libexec/mysqld(handle_fatal_signal+0x515)[0x556bea5554a5] sigaction.c:0(__restore_rt)[0x7fee336755d0] :0(__GI_raise)[0x7fee31d9f207] :0(__GI_abort)[0x7fee31da08f8] /usr/libexec/mysqld(+0x2d73b7)[0x556bea3883b7] /usr/libexec/mysqld(+0x6f87d0)[0x556bea7a97d0] /usr/libexec/mysqld(+0x657ade)[0x556bea708ade] /usr/libexec/mysqld(+0x671153)[0x556bea722153] /usr/libexec/mysqld(+0x666faf)[0x556bea717faf] /usr/libexec/mysqld(+0x668d94)[0x556bea719d94] /usr/libexec/mysqld(+0x66a6c7)[0x556bea71b6c7] /usr/libexec/mysqld(+0x60a5a0)[0x556bea6bb5a0] /usr/libexec/mysqld(+0x60b54b)[0x556bea6bc54b] /usr/libexec/mysqld(_Z19ha_commit_one_phaseP3THDb+0x80)[0x556bea557ac0] /usr/libexec/mysqld(_Z15ha_commit_transP3THDb+0x356)[0x556bea558236] /usr/libexec/mysqld(_Z17trans_commit_stmtP3THD+0x1b)[0x556bea4eb3bb] /usr/libexec/mysqld(_Z21mysql_execute_commandP3THD+0x3dc)[0x556bea4239ec] /usr/libexec/mysqld(_Z11mysql_parseP3THDPcjP12Parser_state+0x125)[0x556bea42a445] /usr/libexec/mysqld(_Z16dispatch_command19enum_server_commandP3THDPcj+0x1750)[0x556bea42c4a0] /usr/libexec/mysqld(_Z24do_handle_one_connectionP3THD+0x1c2)[0x556bea4dea22] /usr/libexec/mysqld(handle_one_connection+0x4a)[0x556bea4deaca] pthread_create.c:0(start_thread)[0x7fee3366ddd5] /lib64/libc.so.6(clone+0x6d)[0x7fee31e66ead] Trying to get some variables. Some pointers may be invalid and cause the dump to abort. Query (0x7fedec004c18): UPDATE `ipaddresses` SET `lastSeen`='2019-04-24 06:30:01' WHERE `id`='5956' Connection ID (thread ID): 12 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=on,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=off,table_elimination=on,extended_keys=off 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. 190424 06:30:13 mysqld_safe Number of processes running now: 0 190424 06:30:13 mysqld_safe mysqld restarted 190424 6:30:13 [Note] /usr/libexec/mysqld (mysqld 5.5.60-MariaDB) starting as process 31559 ... 190424 6:30:13 InnoDB: The InnoDB memory heap is disabled 190424 6:30:13 InnoDB: Mutexes and rw_locks use GCC atomic builtins 190424 6:30:13 InnoDB: Compressed tables use zlib 1.2.7 190424 6:30:13 InnoDB: Using Linux native AIO 190424 6:30:13 InnoDB: Initializing buffer pool, size = 128.0M 190424 6:30:13 InnoDB: Completed initialization of buffer pool 190424 6:30:13 InnoDB: highest supported file format is Barracuda. 190424 6:30:13 InnoDB: Starting crash recovery from checkpoint LSN=18896685 InnoDB: Restoring possible half-written data pages from the doublewrite buffer... 190424 6:30:13 InnoDB: Starting final batch to recover 2 pages from redo log 190424 6:30:14 InnoDB: Waiting for the background threads to start 190424 6:30:15 Percona XtraDB (http://www.percona.com) 5.5.59-MariaDB-38.11 started; log sequence number 18927170 190424 6:30:15 [Note] Plugin 'FEEDBACK' is disabled. 190424 6:30:15 [Note] Server socket created on IP: '0.0.0.0'. 190424 6:30:15 [Note] Event Scheduler: Loaded 0 events 190424 6:30:15 [Note] /usr/libexec/mysqld: ready for connections. Version: '5.5.60-MariaDB' socket: '/data/mysql/mysql.sock' port: 3306 MariaDB Server 190424 6:45:13 InnoDB: Assertion failure in thread 140133375944448 in file fut0lst.ic line 83 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: http://dev.mysql.com/doc/refman/5.5/en/forcing-innodb-recovery.html InnoDB: about forcing recovery. 190424 6:45:13 [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 http://kb.askmonty.org/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: 5.5.60-MariaDB key_buffer_size=134217728 read_buffer_size=131072 max_used_connections=3 max_threads=153 thread_count=1 It is possible that mysqld could use up to key_buffer_size + (read_buffer_size + sort_buffer_size)*max_threads = 466718 K bytes of memory Hope that's ok; if not, decrease some variables in the equation. Thread pointer: 0x556a21510ab0 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 = 0x7f7358181d80 thread_stack 0x48000 /usr/libexec/mysqld(my_print_stacktrace+0x3d)[0x556a1f006cbd] /usr/libexec/mysqld(handle_fatal_signal+0x515)[0x556a1ec1b4a5] sigaction.c:0(__restore_rt)[0x7f735d7e05d0] :0(__GI_raise)[0x7f735bf0a207] :0(__GI_abort)[0x7f735bf0b8f8] /usr/libexec/mysqld(+0x2d73b7)[0x556a1ea4e3b7] /usr/libexec/mysqld(+0x6f87d0)[0x556a1ee6f7d0] /usr/libexec/mysqld(+0x657ade)[0x556a1edceade] /usr/libexec/mysqld(+0x671153)[0x556a1ede8153] /usr/libexec/mysqld(+0x666faf)[0x556a1edddfaf] /usr/libexec/mysqld(+0x668d94)[0x556a1eddfd94] /usr/libexec/mysqld(+0x66a6c7)[0x556a1ede16c7] /usr/libexec/mysqld(+0x60a5a0)[0x556a1ed815a0] /usr/libexec/mysqld(+0x60b54b)[0x556a1ed8254b] /usr/libexec/mysqld(_Z19ha_commit_one_phaseP3THDb+0x80)[0x556a1ec1dac0] /usr/libexec/mysqld(_Z15ha_commit_transP3THDb+0x356)[0x556a1ec1e236] /usr/libexec/mysqld(_Z17trans_commit_stmtP3THD+0x1b)[0x556a1ebb13bb] /usr/libexec/mysqld(_Z21mysql_execute_commandP3THD+0x3dc)[0x556a1eae99ec] /usr/libexec/mysqld(_Z11mysql_parseP3THDPcjP12Parser_state+0x125)[0x556a1eaf0445] /usr/libexec/mysqld(_Z16dispatch_command19enum_server_commandP3THDPcj+0x1750)[0x556a1eaf24a0] /usr/libexec/mysqld(_Z24do_handle_one_connectionP3THD+0x1c2)[0x556a1eba4a22] /usr/libexec/mysqld(handle_one_connection+0x4a)[0x556a1eba4aca] pthread_create.c:0(start_thread)[0x7f735d7d8dd5] /lib64/libc.so.6(clone+0x6d)[0x7f735bfd1ead] Trying to get some variables. Some pointers may be invalid and cause the dump to abort. Query (0x7f7318004c18): UPDATE `ipaddresses` SET `lastSeen`='2019-04-24 06:45:01' WHERE `id`='5956' Connection ID (thread ID): 12 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=on,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=off,table_elimination=on,extended_keys=off 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. 190424 06:45:13 mysqld_safe Number of processes running now: 0 190424 06:45:13 mysqld_safe mysqld restarted 190424 6:45:13 [Note] /usr/libexec/mysqld (mysqld 5.5.60-MariaDB) starting as process 615 ... 190424 6:45:14 InnoDB: The InnoDB memory heap is disabled 190424 6:45:14 InnoDB: Mutexes and rw_locks use GCC atomic builtins 190424 6:45:14 InnoDB: Compressed tables use zlib 1.2.7 190424 6:45:14 InnoDB: Using Linux native AIO 190424 6:45:14 InnoDB: Initializing buffer pool, size = 128.0M 190424 6:45:14 InnoDB: Completed initialization of buffer pool 190424 6:45:14 InnoDB: highest supported file format is Barracuda. 190424 6:45:14 InnoDB: Starting crash recovery from checkpoint LSN=18933048 InnoDB: Restoring possible half-written data pages from the doublewrite buffer... 190424 6:45:14 InnoDB: Starting final batch to recover 2 pages from redo log 190424 6:45:14 InnoDB: Waiting for the background threads to start 190424 6:45:15 Percona XtraDB (http://www.percona.com) 5.5.59-MariaDB-38.11 started; log sequence number 18963533 190424 6:45:15 [Note] Plugin 'FEEDBACK' is disabled. 190424 6:45:15 [Note] Server socket created on IP: '0.0.0.0'. 190424 6:45:15 [Note] Event Scheduler: Loaded 0 events 190424 6:45:15 [Note] /usr/libexec/mysqld: ready for connections. Version: '5.5.60-MariaDB' socket: '/data/mysql/mysql.sock' port: 3306 MariaDB Server 190424 7:00:14 InnoDB: Assertion failure in thread 139770702972672 in file fut0lst.ic line 83 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: http://dev.mysql.com/doc/refman/5.5/en/forcing-innodb-recovery.html InnoDB: about forcing recovery. 190424 7:00:14 [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 http://kb.askmonty.org/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: 5.5.60-MariaDB key_buffer_size=134217728 read_buffer_size=131072 max_used_connections=3 max_threads=153 thread_count=1 It is possible that mysqld could use up to key_buffer_size + (read_buffer_size + sort_buffer_size)*max_threads = 466718 K bytes of memory Hope that's ok; if not, decrease some variables in the equation. Thread pointer: 0x562a9e988ab0 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 = 0x7f1ee719bd80 thread_stack 0x48000 /usr/libexec/mysqld(my_print_stacktrace+0x3d)[0x562a9c1adcbd] /usr/libexec/mysqld(handle_fatal_signal+0x515)[0x562a9bdc24a5] sigaction.c:0(__restore_rt)[0x7f1f0444a5d0] :0(__GI_raise)[0x7f1f02b74207] :0(__GI_abort)[0x7f1f02b758f8] /usr/libexec/mysqld(+0x2d73b7)[0x562a9bbf53b7] /usr/libexec/mysqld(+0x6f87d0)[0x562a9c0167d0] /usr/libexec/mysqld(+0x657ade)[0x562a9bf75ade] /usr/libexec/mysqld(+0x671153)[0x562a9bf8f153] /usr/libexec/mysqld(+0x666faf)[0x562a9bf84faf] /usr/libexec/mysqld(+0x668d94)[0x562a9bf86d94] /usr/libexec/mysqld(+0x66a6c7)[0x562a9bf886c7] /usr/libexec/mysqld(+0x60a5a0)[0x562a9bf285a0] /usr/libexec/mysqld(+0x60b54b)[0x562a9bf2954b] /usr/libexec/mysqld(_Z19ha_commit_one_phaseP3THDb+0x80)[0x562a9bdc4ac0] /usr/libexec/mysqld(_Z15ha_commit_transP3THDb+0x356)[0x562a9bdc5236] /usr/libexec/mysqld(_Z17trans_commit_stmtP3THD+0x1b)[0x562a9bd583bb] /usr/libexec/mysqld(_Z21mysql_execute_commandP3THD+0x3dc)[0x562a9bc909ec] /usr/libexec/mysqld(_Z11mysql_parseP3THDPcjP12Parser_state+0x125)[0x562a9bc97445] /usr/libexec/mysqld(_Z16dispatch_command19enum_server_commandP3THDPcj+0x1750)[0x562a9bc994a0] /usr/libexec/mysqld(_Z24do_handle_one_connectionP3THD+0x1c2)[0x562a9bd4ba22] /usr/libexec/mysqld(handle_one_connection+0x4a)[0x562a9bd4baca] pthread_create.c:0(start_thread)[0x7f1f04442dd5] /lib64/libc.so.6(clone+0x6d)[0x7f1f02c3bead] Trying to get some variables. Some pointers may be invalid and cause the dump to abort. Query (0x7f1ebc004c18): UPDATE `ipaddresses` SET `lastSeen`='2019-04-24 07:00:02' WHERE `id`='5956' Connection ID (thread ID): 12 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=on,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=off,table_elimination=on,extended_keys=off 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. 190424 07:00:14 mysqld_safe Number of processes running now: 0 190424 07:00:14 mysqld_safe mysqld restarted 190424 7:00:14 [Note] /usr/libexec/mysqld (mysqld 5.5.60-MariaDB) starting as process 2641 ... 190424 7:00:14 InnoDB: The InnoDB memory heap is disabled 190424 7:00:14 InnoDB: Mutexes and rw_locks use GCC atomic builtins 190424 7:00:14 InnoDB: Compressed tables use zlib 1.2.7 190424 7:00:14 InnoDB: Using Linux native AIO 190424 7:00:14 InnoDB: Initializing buffer pool, size = 128.0M 190424 7:00:14 InnoDB: Completed initialization of buffer pool 190424 7:00:14 InnoDB: highest supported file format is Barracuda. 190424 7:00:14 InnoDB: Starting crash recovery from checkpoint LSN=18969411 InnoDB: Restoring possible half-written data pages from the doublewrite buffer... 190424 7:00:14 InnoDB: Starting final batch to recover 2 pages from redo log 190424 7:00:15 InnoDB: Waiting for the background threads to start 190424 7:00:16 Percona XtraDB (http://www.percona.com) 5.5.59-MariaDB-38.11 started; log sequence number 18999896 190424 7:00:16 [Note] Plugin 'FEEDBACK' is disabled. 190424 7:00:16 [Note] Server socket created on IP: '0.0.0.0'. 190424 7:00:16 [Note] Event Scheduler: Loaded 0 events 190424 7:00:16 [Note] /usr/libexec/mysqld: ready for connections. Version: '5.5.60-MariaDB' socket: '/data/mysql/mysql.sock' port: 3306 MariaDB Server 190424 7:15:13 InnoDB: Assertion failure in thread 140047745677056 in file fut0lst.ic line 83 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: http://dev.mysql.com/doc/refman/5.5/en/forcing-innodb-recovery.html InnoDB: about forcing recovery. 190424 7:15:13 [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 http://kb.askmonty.org/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: 5.5.60-MariaDB key_buffer_size=134217728 read_buffer_size=131072 max_used_connections=3 max_threads=153 thread_count=1 It is possible that mysqld could use up to key_buffer_size + (read_buffer_size + sort_buffer_size)*max_threads = 466718 K bytes of memory Hope that's ok; if not, decrease some variables in the equation. Thread pointer: 0x55719460fab0 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 = 0x7f5f6821ed80 thread_stack 0x48000 /usr/libexec/mysqld(my_print_stacktrace+0x3d)[0x55719244ccbd] /usr/libexec/mysqld(handle_fatal_signal+0x515)[0x5571920614a5] sigaction.c:0(__restore_rt)[0x7f5f6f8815d0] :0(__GI_raise)[0x7f5f6dfab207] :0(__GI_abort)[0x7f5f6dfac8f8] /usr/libexec/mysqld(+0x2d73b7)[0x557191e943b7] /usr/libexec/mysqld(+0x6f87d0)[0x5571922b57d0] /usr/libexec/mysqld(+0x657ade)[0x557192214ade] /usr/libexec/mysqld(+0x671153)[0x55719222e153] /usr/libexec/mysqld(+0x666faf)[0x557192223faf] /usr/libexec/mysqld(+0x668d94)[0x557192225d94] /usr/libexec/mysqld(+0x66a6c7)[0x5571922276c7] /usr/libexec/mysqld(+0x60a5a0)[0x5571921c75a0] /usr/libexec/mysqld(+0x60b54b)[0x5571921c854b] /usr/libexec/mysqld(_Z19ha_commit_one_phaseP3THDb+0x80)[0x557192063ac0] /usr/libexec/mysqld(_Z15ha_commit_transP3THDb+0x356)[0x557192064236] /usr/libexec/mysqld(_Z17trans_commit_stmtP3THD+0x1b)[0x557191ff73bb] /usr/libexec/mysqld(_Z21mysql_execute_commandP3THD+0x3dc)[0x557191f2f9ec] /usr/libexec/mysqld(_Z11mysql_parseP3THDPcjP12Parser_state+0x125)[0x557191f36445] /usr/libexec/mysqld(_Z16dispatch_command19enum_server_commandP3THDPcj+0x1750)[0x557191f384a0] /usr/libexec/mysqld(_Z24do_handle_one_connectionP3THD+0x1c2)[0x557191feaa22] /usr/libexec/mysqld(handle_one_connection+0x4a)[0x557191feaaca] pthread_create.c:0(start_thread)[0x7f5f6f879dd5] /lib64/libc.so.6(clone+0x6d)[0x7f5f6e072ead] Trying to get some variables. Some pointers may be invalid and cause the dump to abort. Query (0x7f5f28004c18): UPDATE `ipaddresses` SET `lastSeen`='2019-04-24 07:15:01' WHERE `id`='5956' Connection ID (thread ID): 12 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=on,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=off,table_elimination=on,extended_keys=off 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. 190424 07:15:13 mysqld_safe Number of processes running now: 0 190424 07:15:13 mysqld_safe mysqld restarted 190424 7:15:14 [Note] /usr/libexec/mysqld (mysqld 5.5.60-MariaDB) starting as process 4193 ... 190424 7:15:14 InnoDB: The InnoDB memory heap is disabled 190424 7:15:14 InnoDB: Mutexes and rw_locks use GCC atomic builtins 190424 7:15:14 InnoDB: Compressed tables use zlib 1.2.7 190424 7:15:14 InnoDB: Using Linux native AIO 190424 7:15:14 InnoDB: Initializing buffer pool, size = 128.0M 190424 7:15:14 InnoDB: Completed initialization of buffer pool 190424 7:15:14 InnoDB: highest supported file format is Barracuda. 190424 7:15:14 InnoDB: Starting crash recovery from checkpoint LSN=19005896 InnoDB: Restoring possible half-written data pages from the doublewrite buffer... 190424 7:15:14 InnoDB: Starting final batch to recover 3 pages from redo log 190424 7:15:14 InnoDB: Waiting for the background threads to start 190424 7:15:15 Percona XtraDB (http://www.percona.com) 5.5.59-MariaDB-38.11 started; log sequence number 19037112 190424 7:15:15 [Note] Plugin 'FEEDBACK' is disabled. 190424 7:15:15 [Note] Server socket created on IP: '0.0.0.0'. 190424 7:15:15 [Note] Event Scheduler: Loaded 0 events 190424 7:15:15 [Note] /usr/libexec/mysqld: ready for connections. Version: '5.5.60-MariaDB' socket: '/data/mysql/mysql.sock' port: 3306 MariaDB Server 190424 7:30:13 InnoDB: Assertion failure in thread 140010299737856 in file fut0lst.ic line 83 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: http://dev.mysql.com/doc/refman/5.5/en/forcing-innodb-recovery.html InnoDB: about forcing recovery. 190424 7:30:13 [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 http://kb.askmonty.org/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: 5.5.60-MariaDB key_buffer_size=134217728 read_buffer_size=131072 max_used_connections=3 max_threads=153 thread_count=1 It is possible that mysqld could use up to key_buffer_size + (read_buffer_size + sort_buffer_size)*max_threads = 466718 K bytes of memory Hope that's ok; if not, decrease some variables in the equation. Thread pointer: 0x561a97f22ab0 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 = 0x7f56b02e3d80 thread_stack 0x48000 /usr/libexec/mysqld(my_print_stacktrace+0x3d)[0x561a958dbcbd] /usr/libexec/mysqld(handle_fatal_signal+0x515)[0x561a954f04a5] sigaction.c:0(__restore_rt)[0x7f56b79465d0] :0(__GI_raise)[0x7f56b6070207] :0(__GI_abort)[0x7f56b60718f8] /usr/libexec/mysqld(+0x2d73b7)[0x561a953233b7] /usr/libexec/mysqld(+0x6f87d0)[0x561a957447d0] /usr/libexec/mysqld(+0x657ade)[0x561a956a3ade] /usr/libexec/mysqld(+0x671153)[0x561a956bd153] /usr/libexec/mysqld(+0x666faf)[0x561a956b2faf] /usr/libexec/mysqld(+0x668d94)[0x561a956b4d94] /usr/libexec/mysqld(+0x66a6c7)[0x561a956b66c7] /usr/libexec/mysqld(+0x60a5a0)[0x561a956565a0] /usr/libexec/mysqld(+0x60b54b)[0x561a9565754b] /usr/libexec/mysqld(_Z19ha_commit_one_phaseP3THDb+0x80)[0x561a954f2ac0] /usr/libexec/mysqld(_Z15ha_commit_transP3THDb+0x356)[0x561a954f3236] /usr/libexec/mysqld(_Z17trans_commit_stmtP3THD+0x1b)[0x561a954863bb] /usr/libexec/mysqld(_Z21mysql_execute_commandP3THD+0x3dc)[0x561a953be9ec] /usr/libexec/mysqld(_Z11mysql_parseP3THDPcjP12Parser_state+0x125)[0x561a953c5445] /usr/libexec/mysqld(_Z16dispatch_command19enum_server_commandP3THDPcj+0x1750)[0x561a953c74a0] /usr/libexec/mysqld(_Z24do_handle_one_connectionP3THD+0x1c2)[0x561a95479a22] /usr/libexec/mysqld(handle_one_connection+0x4a)[0x561a95479aca] pthread_create.c:0(start_thread)[0x7f56b793edd5] /lib64/libc.so.6(clone+0x6d)[0x7f56b6137ead] Trying to get some variables. Some pointers may be invalid and cause the dump to abort. Query (0x7f5670004c18): UPDATE `ipaddresses` SET `lastSeen`='2019-04-24 07:30:02' WHERE `id`='5956' Connection ID (thread ID): 12 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=on,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=off,table_elimination=on,extended_keys=off 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. 190424 07:30:14 mysqld_safe Number of processes running now: 0 190424 07:30:14 mysqld_safe mysqld restarted 190424 7:30:14 [Note] /usr/libexec/mysqld (mysqld 5.5.60-MariaDB) starting as process 6277 ... 190424 7:30:14 InnoDB: The InnoDB memory heap is disabled 190424 7:30:14 InnoDB: Mutexes and rw_locks use GCC atomic builtins 190424 7:30:14 InnoDB: Compressed tables use zlib 1.2.7 190424 7:30:14 InnoDB: Using Linux native AIO 190424 7:30:14 InnoDB: Initializing buffer pool, size = 128.0M 190424 7:30:14 InnoDB: Completed initialization of buffer pool 190424 7:30:14 InnoDB: highest supported file format is Barracuda. 190424 7:30:14 InnoDB: Starting crash recovery from checkpoint LSN=19043123 InnoDB: Restoring possible half-written data pages from the doublewrite buffer... 190424 7:30:14 InnoDB: Starting final batch to recover 2 pages from redo log 190424 7:30:14 InnoDB: Waiting for the background threads to start 190424 7:30:15 Percona XtraDB (http://www.percona.com) 5.5.59-MariaDB-38.11 started; log sequence number 19073608 190424 7:30:15 [Note] Plugin 'FEEDBACK' is disabled. 190424 7:30:15 [Note] Server socket created on IP: '0.0.0.0'. 190424 7:30:15 [Note] Event Scheduler: Loaded 0 events 190424 7:30:15 [Note] /usr/libexec/mysqld: ready for connections. Version: '5.5.60-MariaDB' socket: '/data/mysql/mysql.sock' port: 3306 MariaDB Server 190424 7:45:13 InnoDB: Assertion failure in thread 139968423646976 in file fut0lst.ic line 83 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: http://dev.mysql.com/doc/refman/5.5/en/forcing-innodb-recovery.html InnoDB: about forcing recovery. 190424 7:45:13 [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 http://kb.askmonty.org/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: 5.5.60-MariaDB key_buffer_size=134217728 read_buffer_size=131072 max_used_connections=3 max_threads=153 thread_count=1 It is possible that mysqld could use up to key_buffer_size + (read_buffer_size + sort_buffer_size)*max_threads = 466718 K bytes of memory Hope that's ok; if not, decrease some variables in the equation. Thread pointer: 0x563e8dd51ab0 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 = 0x7f4cf02bcd80 thread_stack 0x48000 /usr/libexec/mysqld(my_print_stacktrace+0x3d)[0x563e8bc29cbd] /usr/libexec/mysqld(handle_fatal_signal+0x515)[0x563e8b83e4a5] sigaction.c:0(__restore_rt)[0x7f4cf41c35d0] :0(__GI_raise)[0x7f4cf28ed207] :0(__GI_abort)[0x7f4cf28ee8f8] /usr/libexec/mysqld(+0x2d73b7)[0x563e8b6713b7] /usr/libexec/mysqld(+0x6f87d0)[0x563e8ba927d0] /usr/libexec/mysqld(+0x657ade)[0x563e8b9f1ade] /usr/libexec/mysqld(+0x671153)[0x563e8ba0b153] /usr/libexec/mysqld(+0x666faf)[0x563e8ba00faf] /usr/libexec/mysqld(+0x668d94)[0x563e8ba02d94] /usr/libexec/mysqld(+0x66a6c7)[0x563e8ba046c7] /usr/libexec/mysqld(+0x60a5a0)[0x563e8b9a45a0] /usr/libexec/mysqld(+0x60b54b)[0x563e8b9a554b] /usr/libexec/mysqld(_Z19ha_commit_one_phaseP3THDb+0x80)[0x563e8b840ac0] /usr/libexec/mysqld(_Z15ha_commit_transP3THDb+0x356)[0x563e8b841236] /usr/libexec/mysqld(_Z17trans_commit_stmtP3THD+0x1b)[0x563e8b7d43bb] /usr/libexec/mysqld(_Z21mysql_execute_commandP3THD+0x3dc)[0x563e8b70c9ec] /usr/libexec/mysqld(_Z11mysql_parseP3THDPcjP12Parser_state+0x125)[0x563e8b713445] /usr/libexec/mysqld(_Z16dispatch_command19enum_server_commandP3THDPcj+0x1750)[0x563e8b7154a0] /usr/libexec/mysqld(_Z24do_handle_one_connectionP3THD+0x1c2)[0x563e8b7c7a22] /usr/libexec/mysqld(handle_one_connection+0x4a)[0x563e8b7c7aca] pthread_create.c:0(start_thread)[0x7f4cf41bbdd5] /lib64/libc.so.6(clone+0x6d)[0x7f4cf29b4ead] Trying to get some variables. Some pointers may be invalid and cause the dump to abort. Query (0x7f4cac004c18): UPDATE `ipaddresses` SET `lastSeen`='2019-04-24 07:45:01' WHERE `id`='5956' Connection ID (thread ID): 12 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=on,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=off,table_elimination=on,extended_keys=off 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. 190424 07:45:14 mysqld_safe Number of processes running now: 0 190424 07:45:14 mysqld_safe mysqld restarted 190424 7:45:14 [Note] /usr/libexec/mysqld (mysqld 5.5.60-MariaDB) starting as process 7826 ... 190424 7:45:14 InnoDB: The InnoDB memory heap is disabled 190424 7:45:14 InnoDB: Mutexes and rw_locks use GCC atomic builtins 190424 7:45:14 InnoDB: Compressed tables use zlib 1.2.7 190424 7:45:14 InnoDB: Using Linux native AIO 190424 7:45:14 InnoDB: Initializing buffer pool, size = 128.0M 190424 7:45:14 InnoDB: Completed initialization of buffer pool 190424 7:45:14 InnoDB: highest supported file format is Barracuda. 190424 7:45:14 InnoDB: Starting crash recovery from checkpoint LSN=19079486 InnoDB: Restoring possible half-written data pages from the doublewrite buffer... 190424 7:45:14 InnoDB: Starting final batch to recover 2 pages from redo log 190424 7:45:14 InnoDB: Waiting for the background threads to start 190424 7:45:15 Percona XtraDB (http://www.percona.com) 5.5.59-MariaDB-38.11 started; log sequence number 19109971 190424 7:45:15 [Note] Plugin 'FEEDBACK' is disabled. 190424 7:45:15 [Note] Server socket created on IP: '0.0.0.0'. 190424 7:45:15 [Note] Event Scheduler: Loaded 0 events 190424 7:45:15 [Note] /usr/libexec/mysqld: ready for connections. Version: '5.5.60-MariaDB' socket: '/data/mysql/mysql.sock' port: 3306 MariaDB Server 190424 8:00:13 InnoDB: Assertion failure in thread 140627163432704 in file fut0lst.ic line 83 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: http://dev.mysql.com/doc/refman/5.5/en/forcing-innodb-recovery.html InnoDB: about forcing recovery. 190424 8:00:13 [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 http://kb.askmonty.org/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: 5.5.60-MariaDB key_buffer_size=134217728 read_buffer_size=131072 max_used_connections=3 max_threads=153 thread_count=1 It is possible that mysqld could use up to key_buffer_size + (read_buffer_size + sort_buffer_size)*max_threads = 466718 K bytes of memory Hope that's ok; if not, decrease some variables in the equation. Thread pointer: 0x561e8b911ab0 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 = 0x7fe6501f3d80 thread_stack 0x48000 /usr/libexec/mysqld(my_print_stacktrace+0x3d)[0x561e88ca3cbd] /usr/libexec/mysqld(handle_fatal_signal+0x515)[0x561e888b84a5] sigaction.c:0(__restore_rt)[0x7fe653ee75d0] :0(__GI_raise)[0x7fe652611207] :0(__GI_abort)[0x7fe6526128f8] /usr/libexec/mysqld(+0x2d73b7)[0x561e886eb3b7] /usr/libexec/mysqld(+0x6f87d0)[0x561e88b0c7d0] /usr/libexec/mysqld(+0x657ade)[0x561e88a6bade] /usr/libexec/mysqld(+0x671153)[0x561e88a85153] /usr/libexec/mysqld(+0x666faf)[0x561e88a7afaf] /usr/libexec/mysqld(+0x668d94)[0x561e88a7cd94] /usr/libexec/mysqld(+0x66a6c7)[0x561e88a7e6c7] /usr/libexec/mysqld(+0x60a5a0)[0x561e88a1e5a0] /usr/libexec/mysqld(+0x60b54b)[0x561e88a1f54b] /usr/libexec/mysqld(_Z19ha_commit_one_phaseP3THDb+0x80)[0x561e888baac0] /usr/libexec/mysqld(_Z15ha_commit_transP3THDb+0x356)[0x561e888bb236] /usr/libexec/mysqld(_Z17trans_commit_stmtP3THD+0x1b)[0x561e8884e3bb] /usr/libexec/mysqld(_Z21mysql_execute_commandP3THD+0x3dc)[0x561e887869ec] /usr/libexec/mysqld(_Z11mysql_parseP3THDPcjP12Parser_state+0x125)[0x561e8878d445] /usr/libexec/mysqld(_Z16dispatch_command19enum_server_commandP3THDPcj+0x1750)[0x561e8878f4a0] /usr/libexec/mysqld(_Z24do_handle_one_connectionP3THD+0x1c2)[0x561e88841a22] /usr/libexec/mysqld(handle_one_connection+0x4a)[0x561e88841aca] pthread_create.c:0(start_thread)[0x7fe653edfdd5] /lib64/libc.so.6(clone+0x6d)[0x7fe6526d8ead] Trying to get some variables. Some pointers may be invalid and cause the dump to abort. Query (0x7fe60c004c18): UPDATE `ipaddresses` SET `lastSeen`='2019-04-24 08:00:01' WHERE `id`='5956' Connection ID (thread ID): 12 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=on,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=off,table_elimination=on,extended_keys=off 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. 190424 08:00:13 mysqld_safe Number of processes running now: 0 190424 08:00:13 mysqld_safe mysqld restarted 190424 8:00:13 [Note] /usr/libexec/mysqld (mysqld 5.5.60-MariaDB) starting as process 9830 ... 190424 8:00:13 InnoDB: The InnoDB memory heap is disabled 190424 8:00:13 InnoDB: Mutexes and rw_locks use GCC atomic builtins 190424 8:00:13 InnoDB: Compressed tables use zlib 1.2.7 190424 8:00:13 InnoDB: Using Linux native AIO 190424 8:00:13 InnoDB: Initializing buffer pool, size = 128.0M 190424 8:00:13 InnoDB: Completed initialization of buffer pool 190424 8:00:13 InnoDB: highest supported file format is Barracuda. 190424 8:00:13 InnoDB: Starting crash recovery from checkpoint LSN=19115849 InnoDB: Restoring possible half-written data pages from the doublewrite buffer... 190424 8:00:13 InnoDB: Starting final batch to recover 2 pages from redo log 190424 8:00:14 InnoDB: Waiting for the background threads to start 190424 8:00:15 Percona XtraDB (http://www.percona.com) 5.5.59-MariaDB-38.11 started; log sequence number 19146334 190424 8:00:15 [Note] Plugin 'FEEDBACK' is disabled. 190424 8:00:15 [Note] Server socket created on IP: '0.0.0.0'. 190424 8:00:15 [Note] Event Scheduler: Loaded 0 events 190424 8:00:15 [Note] /usr/libexec/mysqld: ready for connections. Version: '5.5.60-MariaDB' socket: '/data/mysql/mysql.sock' port: 3306 MariaDB Server 190424 8:15:13 InnoDB: Assertion failure in thread 139857542178560 in file fut0lst.ic line 83 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: http://dev.mysql.com/doc/refman/5.5/en/forcing-innodb-recovery.html InnoDB: about forcing recovery. 190424 8:15:13 [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 http://kb.askmonty.org/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: 5.5.60-MariaDB key_buffer_size=134217728 read_buffer_size=131072 max_used_connections=3 max_threads=153 thread_count=1 It is possible that mysqld could use up to key_buffer_size + (read_buffer_size + sort_buffer_size)*max_threads = 466718 K bytes of memory Hope that's ok; if not, decrease some variables in the equation. Thread pointer: 0x561366039ab0 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 = 0x7f331f1edd80 thread_stack 0x48000 /usr/libexec/mysqld(my_print_stacktrace+0x3d)[0x56136383ccbd] /usr/libexec/mysqld(handle_fatal_signal+0x515)[0x5613634514a5] sigaction.c:0(__restore_rt)[0x7f333c4cc5d0] :0(__GI_raise)[0x7f333abf6207] :0(__GI_abort)[0x7f333abf78f8] /usr/libexec/mysqld(+0x2d73b7)[0x5613632843b7] /usr/libexec/mysqld(+0x6f87d0)[0x5613636a57d0] /usr/libexec/mysqld(+0x657ade)[0x561363604ade] /usr/libexec/mysqld(+0x671153)[0x56136361e153] /usr/libexec/mysqld(+0x666faf)[0x561363613faf] /usr/libexec/mysqld(+0x668d94)[0x561363615d94] /usr/libexec/mysqld(+0x66a6c7)[0x5613636176c7] /usr/libexec/mysqld(+0x60a5a0)[0x5613635b75a0] /usr/libexec/mysqld(+0x60b54b)[0x5613635b854b] /usr/libexec/mysqld(_Z19ha_commit_one_phaseP3THDb+0x80)[0x561363453ac0] /usr/libexec/mysqld(_Z15ha_commit_transP3THDb+0x356)[0x561363454236] /usr/libexec/mysqld(_Z17trans_commit_stmtP3THD+0x1b)[0x5613633e73bb] /usr/libexec/mysqld(_Z21mysql_execute_commandP3THD+0x3dc)[0x56136331f9ec] /usr/libexec/mysqld(_Z11mysql_parseP3THDPcjP12Parser_state+0x125)[0x561363326445] /usr/libexec/mysqld(_Z16dispatch_command19enum_server_commandP3THDPcj+0x1750)[0x5613633284a0] /usr/libexec/mysqld(_Z24do_handle_one_connectionP3THD+0x1c2)[0x5613633daa22] /usr/libexec/mysqld(handle_one_connection+0x4a)[0x5613633daaca] pthread_create.c:0(start_thread)[0x7f333c4c4dd5] /lib64/libc.so.6(clone+0x6d)[0x7f333acbdead] Trying to get some variables. Some pointers may be invalid and cause the dump to abort. Query (0x7f32f4004c18): UPDATE `ipaddresses` SET `lastSeen`='2019-04-24 08:15:01' WHERE `id`='5956' Connection ID (thread ID): 12 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=on,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=off,table_elimination=on,extended_keys=off 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. 190424 08:15:13 mysqld_safe Number of processes running now: 0 190424 08:15:13 mysqld_safe mysqld restarted 190424 8:15:14 [Note] /usr/libexec/mysqld (mysqld 5.5.60-MariaDB) starting as process 11379 ... 190424 8:15:14 InnoDB: The InnoDB memory heap is disabled 190424 8:15:14 InnoDB: Mutexes and rw_locks use GCC atomic builtins 190424 8:15:14 InnoDB: Compressed tables use zlib 1.2.7 190424 8:15:14 InnoDB: Using Linux native AIO 190424 8:15:14 InnoDB: Initializing buffer pool, size = 128.0M 190424 8:15:14 InnoDB: Completed initialization of buffer pool 190424 8:15:14 InnoDB: highest supported file format is Barracuda. 190424 8:15:14 InnoDB: Starting crash recovery from checkpoint LSN=19152212 InnoDB: Restoring possible half-written data pages from the doublewrite buffer... 190424 8:15:14 InnoDB: Starting final batch to recover 2 pages from redo log 190424 8:15:14 InnoDB: Waiting for the background threads to start 190424 8:15:15 Percona XtraDB (http://www.percona.com) 5.5.59-MariaDB-38.11 started; log sequence number 19182697 190424 8:15:15 [Note] Plugin 'FEEDBACK' is disabled. 190424 8:15:15 [Note] Server socket created on IP: '0.0.0.0'. 190424 8:15:15 [Note] Event Scheduler: Loaded 0 events 190424 8:15:15 [Note] /usr/libexec/mysqld: ready for connections. Version: '5.5.60-MariaDB' socket: '/data/mysql/mysql.sock' port: 3306 MariaDB Server 190424 8:30:14 InnoDB: Assertion failure in thread 139645827245824 in file fut0lst.ic line 83 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: http://dev.mysql.com/doc/refman/5.5/en/forcing-innodb-recovery.html InnoDB: about forcing recovery. 190424 8:30:14 [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 http://kb.askmonty.org/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: 5.5.60-MariaDB key_buffer_size=134217728 read_buffer_size=131072 max_used_connections=3 max_threads=153 thread_count=1 It is possible that mysqld could use up to key_buffer_size + (read_buffer_size + sort_buffer_size)*max_threads = 466718 K bytes of memory Hope that's ok; if not, decrease some variables in the equation. Thread pointer: 0x559aa08e3ab0 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 = 0x7f01d3ed5d80 thread_stack 0x48000 /usr/libexec/mysqld(my_print_stacktrace+0x3d)[0x559a9e468cbd] /usr/libexec/mysqld(handle_fatal_signal+0x515)[0x559a9e07d4a5] sigaction.c:0(__restore_rt)[0x7f01f115d5d0] :0(__GI_raise)[0x7f01ef887207] :0(__GI_abort)[0x7f01ef8888f8] /usr/libexec/mysqld(+0x2d73b7)[0x559a9deb03b7] /usr/libexec/mysqld(+0x6f87d0)[0x559a9e2d17d0] /usr/libexec/mysqld(+0x657ade)[0x559a9e230ade] /usr/libexec/mysqld(+0x671153)[0x559a9e24a153] /usr/libexec/mysqld(+0x666faf)[0x559a9e23ffaf] /usr/libexec/mysqld(+0x668d94)[0x559a9e241d94] /usr/libexec/mysqld(+0x66a6c7)[0x559a9e2436c7] /usr/libexec/mysqld(+0x60a5a0)[0x559a9e1e35a0] /usr/libexec/mysqld(+0x60b54b)[0x559a9e1e454b] /usr/libexec/mysqld(_Z19ha_commit_one_phaseP3THDb+0x80)[0x559a9e07fac0] /usr/libexec/mysqld(_Z15ha_commit_transP3THDb+0x356)[0x559a9e080236] /usr/libexec/mysqld(_Z17trans_commit_stmtP3THD+0x1b)[0x559a9e0133bb] /usr/libexec/mysqld(_Z21mysql_execute_commandP3THD+0x3dc)[0x559a9df4b9ec] /usr/libexec/mysqld(_Z11mysql_parseP3THDPcjP12Parser_state+0x125)[0x559a9df52445] /usr/libexec/mysqld(_Z16dispatch_command19enum_server_commandP3THDPcj+0x1750)[0x559a9df544a0] /usr/libexec/mysqld(_Z24do_handle_one_connectionP3THD+0x1c2)[0x559a9e006a22] /usr/libexec/mysqld(handle_one_connection+0x4a)[0x559a9e006aca] pthread_create.c:0(start_thread)[0x7f01f1155dd5] /lib64/libc.so.6(clone+0x6d)[0x7f01ef94eead] Trying to get some variables. Some pointers may be invalid and cause the dump to abort. Query (0x7f01b0004c18): UPDATE `ipaddresses` SET `lastSeen`='2019-04-24 08:30:02' WHERE `id`='5956' Connection ID (thread ID): 12 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=on,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=off,table_elimination=on,extended_keys=off 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. 190424 08:30:14 mysqld_safe Number of processes running now: 0 190424 08:30:14 mysqld_safe mysqld restarted 190424 8:30:15 [Note] /usr/libexec/mysqld (mysqld 5.5.60-MariaDB) starting as process 13391 ... 190424 8:30:15 InnoDB: The InnoDB memory heap is disabled 190424 8:30:15 InnoDB: Mutexes and rw_locks use GCC atomic builtins 190424 8:30:15 InnoDB: Compressed tables use zlib 1.2.7 190424 8:30:15 InnoDB: Using Linux native AIO 190424 8:30:15 InnoDB: Initializing buffer pool, size = 128.0M 190424 8:30:15 InnoDB: Completed initialization of buffer pool 190424 8:30:15 InnoDB: highest supported file format is Barracuda. 190424 8:30:15 InnoDB: Starting crash recovery from checkpoint LSN=19193592 InnoDB: Restoring possible half-written data pages from the doublewrite buffer... 190424 8:30:15 InnoDB: Starting final batch to recover 2 pages from redo log 190424 8:30:15 InnoDB: Waiting for the background threads to start 190424 8:30:16 Percona XtraDB (http://www.percona.com) 5.5.59-MariaDB-38.11 started; log sequence number 19224077 190424 8:30:16 [Note] Plugin 'FEEDBACK' is disabled. 190424 8:30:16 [Note] Server socket created on IP: '0.0.0.0'. 190424 8:30:16 [Note] Event Scheduler: Loaded 0 events 190424 8:30:16 [Note] /usr/libexec/mysqld: ready for connections. Version: '5.5.60-MariaDB' socket: '/data/mysql/mysql.sock' port: 3306 MariaDB Server 190424 8:45:15 InnoDB: Assertion failure in thread 139691396716288 in file fut0lst.ic line 83 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: http://dev.mysql.com/doc/refman/5.5/en/forcing-innodb-recovery.html InnoDB: about forcing recovery. 190424 8:45:15 [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 http://kb.askmonty.org/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: 5.5.60-MariaDB key_buffer_size=134217728 read_buffer_size=131072 max_used_connections=3 max_threads=153 thread_count=1 It is possible that mysqld could use up to key_buffer_size + (read_buffer_size + sort_buffer_size)*max_threads = 466718 K bytes of memory Hope that's ok; if not, decrease some variables in the equation. Thread pointer: 0x5636832c6ab0 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 = 0x7f0c70144d80 thread_stack 0x48000 /usr/libexec/mysqld(my_print_stacktrace+0x3d)[0x5636802ddcbd] /usr/libexec/mysqld(handle_fatal_signal+0x515)[0x56367fef24a5] sigaction.c:0(__restore_rt)[0x7f0c8d45b5d0] :0(__GI_raise)[0x7f0c8bb85207] :0(__GI_abort)[0x7f0c8bb868f8] /usr/libexec/mysqld(+0x2d73b7)[0x56367fd253b7] /usr/libexec/mysqld(+0x6f87d0)[0x5636801467d0] /usr/libexec/mysqld(+0x657ade)[0x5636800a5ade] /usr/libexec/mysqld(+0x671153)[0x5636800bf153] /usr/libexec/mysqld(+0x666faf)[0x5636800b4faf] /usr/libexec/mysqld(+0x668d94)[0x5636800b6d94] /usr/libexec/mysqld(+0x66a6c7)[0x5636800b86c7] /usr/libexec/mysqld(+0x60a5a0)[0x5636800585a0] /usr/libexec/mysqld(+0x60b54b)[0x56368005954b] /usr/libexec/mysqld(_Z19ha_commit_one_phaseP3THDb+0x80)[0x56367fef4ac0] /usr/libexec/mysqld(_Z15ha_commit_transP3THDb+0x356)[0x56367fef5236] /usr/libexec/mysqld(_Z17trans_commit_stmtP3THD+0x1b)[0x56367fe883bb] /usr/libexec/mysqld(_Z21mysql_execute_commandP3THD+0x3dc)[0x56367fdc09ec] /usr/libexec/mysqld(_Z11mysql_parseP3THDPcjP12Parser_state+0x125)[0x56367fdc7445] /usr/libexec/mysqld(_Z16dispatch_command19enum_server_commandP3THDPcj+0x1750)[0x56367fdc94a0] /usr/libexec/mysqld(_Z24do_handle_one_connectionP3THD+0x1c2)[0x56367fe7ba22] /usr/libexec/mysqld(handle_one_connection+0x4a)[0x56367fe7baca] pthread_create.c:0(start_thread)[0x7f0c8d453dd5] /lib64/libc.so.6(clone+0x6d)[0x7f0c8bc4cead] Trying to get some variables. Some pointers may be invalid and cause the dump to abort. Query (0x7f0c50004c18): UPDATE `ipaddresses` SET `lastSeen`='2019-04-24 08:45:02' WHERE `id`='5956' Connection ID (thread ID): 12 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=on,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=off,table_elimination=on,extended_keys=off 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. 190424 08:45:15 mysqld_safe Number of processes running now: 0 190424 08:45:15 mysqld_safe mysqld restarted 190424 8:45:15 [Note] /usr/libexec/mysqld (mysqld 5.5.60-MariaDB) starting as process 14931 ... 190424 8:45:15 InnoDB: The InnoDB memory heap is disabled 190424 8:45:15 InnoDB: Mutexes and rw_locks use GCC atomic builtins 190424 8:45:15 InnoDB: Compressed tables use zlib 1.2.7 190424 8:45:15 InnoDB: Using Linux native AIO 190424 8:45:15 InnoDB: Initializing buffer pool, size = 128.0M 190424 8:45:15 InnoDB: Completed initialization of buffer pool 190424 8:45:15 InnoDB: highest supported file format is Barracuda. 190424 8:45:15 InnoDB: Starting crash recovery from checkpoint LSN=19229973 InnoDB: Restoring possible half-written data pages from the doublewrite buffer... 190424 8:45:15 InnoDB: Starting final batch to recover 2 pages from redo log 190424 8:45:16 InnoDB: Waiting for the background threads to start 190424 8:45:17 Percona XtraDB (http://www.percona.com) 5.5.59-MariaDB-38.11 started; log sequence number 19260458 190424 8:45:17 [Note] Plugin 'FEEDBACK' is disabled. 190424 8:45:17 [Note] Server socket created on IP: '0.0.0.0'. 190424 8:45:17 [Note] Event Scheduler: Loaded 0 events 190424 8:45:17 [Note] /usr/libexec/mysqld: ready for connections. Version: '5.5.60-MariaDB' socket: '/data/mysql/mysql.sock' port: 3306 MariaDB Server 190424 9:00:13 InnoDB: Assertion failure in thread 140026740012800 in file fut0lst.ic line 83 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: http://dev.mysql.com/doc/refman/5.5/en/forcing-innodb-recovery.html InnoDB: about forcing recovery. 190424 9:00:13 [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 http://kb.askmonty.org/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: 5.5.60-MariaDB key_buffer_size=134217728 read_buffer_size=131072 max_used_connections=3 max_threads=153 thread_count=1 It is possible that mysqld could use up to key_buffer_size + (read_buffer_size + sort_buffer_size)*max_threads = 466718 K bytes of memory Hope that's ok; if not, decrease some variables in the equation. Thread pointer: 0x55575f6e48f0 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 = 0x7f5a8418ed80 thread_stack 0x48000 /usr/libexec/mysqld(my_print_stacktrace+0x3d)[0x55575bdd6cbd] /usr/libexec/mysqld(handle_fatal_signal+0x515)[0x55575b9eb4a5] sigaction.c:0(__restore_rt)[0x7f5aa14295d0] :0(__GI_raise)[0x7f5a9fb53207] :0(__GI_abort)[0x7f5a9fb548f8] /usr/libexec/mysqld(+0x2d73b7)[0x55575b81e3b7] /usr/libexec/mysqld(+0x6f87d0)[0x55575bc3f7d0] /usr/libexec/mysqld(+0x657ade)[0x55575bb9eade] /usr/libexec/mysqld(+0x671153)[0x55575bbb8153] /usr/libexec/mysqld(+0x666faf)[0x55575bbadfaf] /usr/libexec/mysqld(+0x668d94)[0x55575bbafd94] /usr/libexec/mysqld(+0x66a6c7)[0x55575bbb16c7] /usr/libexec/mysqld(+0x60a5a0)[0x55575bb515a0] /usr/libexec/mysqld(+0x60b54b)[0x55575bb5254b] /usr/libexec/mysqld(_Z19ha_commit_one_phaseP3THDb+0x80)[0x55575b9edac0] /usr/libexec/mysqld(_Z15ha_commit_transP3THDb+0x356)[0x55575b9ee236] /usr/libexec/mysqld(_Z17trans_commit_stmtP3THD+0x1b)[0x55575b9813bb] /usr/libexec/mysqld(_Z21mysql_execute_commandP3THD+0x3dc)[0x55575b8b99ec] /usr/libexec/mysqld(_Z11mysql_parseP3THDPcjP12Parser_state+0x125)[0x55575b8c0445] /usr/libexec/mysqld(_Z16dispatch_command19enum_server_commandP3THDPcj+0x1750)[0x55575b8c24a0] /usr/libexec/mysqld(_Z24do_handle_one_connectionP3THD+0x1c2)[0x55575b974a22] /usr/libexec/mysqld(handle_one_connection+0x4a)[0x55575b974aca] pthread_create.c:0(start_thread)[0x7f5aa1421dd5] /lib64/libc.so.6(clone+0x6d)[0x7f5a9fc1aead] Trying to get some variables. Some pointers may be invalid and cause the dump to abort. Query (0x7f5a60004c18): UPDATE `ipaddresses` SET `lastSeen`='2019-04-24 09:00:01' WHERE `id`='5956' Connection ID (thread ID): 12 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=on,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=off,table_elimination=on,extended_keys=off 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. 190424 09:00:13 mysqld_safe Number of processes running now: 0 190424 09:00:13 mysqld_safe mysqld restarted 190424 9:00:13 [Note] /usr/libexec/mysqld (mysqld 5.5.60-MariaDB) starting as process 16952 ... 190424 9:00:14 InnoDB: The InnoDB memory heap is disabled 190424 9:00:14 InnoDB: Mutexes and rw_locks use GCC atomic builtins 190424 9:00:14 InnoDB: Compressed tables use zlib 1.2.7 190424 9:00:14 InnoDB: Using Linux native AIO 190424 9:00:14 InnoDB: Initializing buffer pool, size = 128.0M 190424 9:00:14 InnoDB: Completed initialization of buffer pool 190424 9:00:14 InnoDB: highest supported file format is Barracuda. 190424 9:00:14 InnoDB: Starting crash recovery from checkpoint LSN=19267198 InnoDB: Restoring possible half-written data pages from the doublewrite buffer... 190424 9:00:14 InnoDB: Starting final batch to recover 2 pages from redo log 190424 9:00:14 InnoDB: Waiting for the background threads to start 190424 9:00:15 Percona XtraDB (http://www.percona.com) 5.5.59-MariaDB-38.11 started; log sequence number 19297667 190424 9:00:15 [Note] Plugin 'FEEDBACK' is disabled. 190424 9:00:15 [Note] Server socket created on IP: '0.0.0.0'. 190424 9:00:15 [Note] Event Scheduler: Loaded 0 events 190424 9:00:15 [Note] /usr/libexec/mysqld: ready for connections. Version: '5.5.60-MariaDB' socket: '/data/mysql/mysql.sock' port: 3306 MariaDB Server 190424 9:15:15 InnoDB: Assertion failure in thread 140663913895680 in file fut0lst.ic line 83 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: http://dev.mysql.com/doc/refman/5.5/en/forcing-innodb-recovery.html InnoDB: about forcing recovery. 190424 9:15:15 [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 http://kb.askmonty.org/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: 5.5.60-MariaDB key_buffer_size=134217728 read_buffer_size=131072 max_used_connections=3 max_threads=153 thread_count=1 It is possible that mysqld could use up to key_buffer_size + (read_buffer_size + sort_buffer_size)*max_threads = 466718 K bytes of memory Hope that's ok; if not, decrease some variables in the equation. Thread pointer: 0x5601ff38bab0 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 = 0x7feede9ecd80 thread_stack 0x48000 /usr/libexec/mysqld(my_print_stacktrace+0x3d)[0x5601fd526cbd] /usr/libexec/mysqld(handle_fatal_signal+0x515)[0x5601fd13b4a5] sigaction.c:0(__restore_rt)[0x7feefbc685d0] :0(__GI_raise)[0x7feefa392207] :0(__GI_abort)[0x7feefa3938f8] /usr/libexec/mysqld(+0x2d73b7)[0x5601fcf6e3b7] /usr/libexec/mysqld(+0x6f87d0)[0x5601fd38f7d0] /usr/libexec/mysqld(+0x657ade)[0x5601fd2eeade] /usr/libexec/mysqld(+0x671153)[0x5601fd308153] /usr/libexec/mysqld(+0x666faf)[0x5601fd2fdfaf] /usr/libexec/mysqld(+0x668d94)[0x5601fd2ffd94] /usr/libexec/mysqld(+0x66a6c7)[0x5601fd3016c7] /usr/libexec/mysqld(+0x60a5a0)[0x5601fd2a15a0] /usr/libexec/mysqld(+0x60b54b)[0x5601fd2a254b] /usr/libexec/mysqld(_Z19ha_commit_one_phaseP3THDb+0x80)[0x5601fd13dac0] /usr/libexec/mysqld(_Z15ha_commit_transP3THDb+0x356)[0x5601fd13e236] /usr/libexec/mysqld(_Z17trans_commit_stmtP3THD+0x1b)[0x5601fd0d13bb] /usr/libexec/mysqld(_Z21mysql_execute_commandP3THD+0x3dc)[0x5601fd0099ec] /usr/libexec/mysqld(_Z11mysql_parseP3THDPcjP12Parser_state+0x125)[0x5601fd010445] /usr/libexec/mysqld(_Z16dispatch_command19enum_server_commandP3THDPcj+0x1750)[0x5601fd0124a0] /usr/libexec/mysqld(_Z24do_handle_one_connectionP3THD+0x1c2)[0x5601fd0c4a22] /usr/libexec/mysqld(handle_one_connection+0x4a)[0x5601fd0c4aca] pthread_create.c:0(start_thread)[0x7feefbc60dd5] /lib64/libc.so.6(clone+0x6d)[0x7feefa459ead] Trying to get some variables. Some pointers may be invalid and cause the dump to abort. Query (0x7feeb4004c18): UPDATE `ipaddresses` SET `lastSeen`='2019-04-24 09:15:02' WHERE `id`='5956' Connection ID (thread ID): 12 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=on,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=off,table_elimination=on,extended_keys=off 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. 190424 09:15:15 mysqld_safe Number of processes running now: 0 190424 09:15:15 mysqld_safe mysqld restarted 190424 9:15:15 [Note] /usr/libexec/mysqld (mysqld 5.5.60-MariaDB) starting as process 18522 ... 190424 9:15:15 InnoDB: The InnoDB memory heap is disabled 190424 9:15:15 InnoDB: Mutexes and rw_locks use GCC atomic builtins 190424 9:15:15 InnoDB: Compressed tables use zlib 1.2.7 190424 9:15:15 InnoDB: Using Linux native AIO 190424 9:15:15 InnoDB: Initializing buffer pool, size = 128.0M 190424 9:15:15 InnoDB: Completed initialization of buffer pool 190424 9:15:15 InnoDB: highest supported file format is Barracuda. 190424 9:15:15 InnoDB: Starting crash recovery from checkpoint LSN=19303560 InnoDB: Restoring possible half-written data pages from the doublewrite buffer... 190424 9:15:15 InnoDB: Starting final batch to recover 2 pages from redo log 190424 9:15:16 InnoDB: Waiting for the background threads to start 190424 9:15:17 Percona XtraDB (http://www.percona.com) 5.5.59-MariaDB-38.11 started; log sequence number 19334029 190424 9:15:17 [Note] Plugin 'FEEDBACK' is disabled. 190424 9:15:17 [Note] Server socket created on IP: '0.0.0.0'. 190424 9:15:17 [Note] Event Scheduler: Loaded 0 events 190424 9:15:17 [Note] /usr/libexec/mysqld: ready for connections. Version: '5.5.60-MariaDB' socket: '/data/mysql/mysql.sock' port: 3306 MariaDB Server 190424 9:30:13 InnoDB: Assertion failure in thread 139899702933248 in file fut0lst.ic line 83 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: http://dev.mysql.com/doc/refman/5.5/en/forcing-innodb-recovery.html InnoDB: about forcing recovery. 190424 9:30:13 [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 http://kb.askmonty.org/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: 5.5.60-MariaDB key_buffer_size=134217728 read_buffer_size=131072 max_used_connections=3 max_threads=153 thread_count=1 It is possible that mysqld could use up to key_buffer_size + (read_buffer_size + sort_buffer_size)*max_threads = 466718 K bytes of memory Hope that's ok; if not, decrease some variables in the equation. Thread pointer: 0x55ed8bb66ab0 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 = 0x7f3cf018ed80 thread_stack 0x48000 /usr/libexec/mysqld(my_print_stacktrace+0x3d)[0x55ed886e6cbd] /usr/libexec/mysqld(handle_fatal_signal+0x515)[0x55ed882fb4a5] sigaction.c:0(__restore_rt)[0x7f3d0d47b5d0] :0(__GI_raise)[0x7f3d0bba5207] :0(__GI_abort)[0x7f3d0bba68f8] /usr/libexec/mysqld(+0x2d73b7)[0x55ed8812e3b7] /usr/libexec/mysqld(+0x6f87d0)[0x55ed8854f7d0] /usr/libexec/mysqld(+0x657ade)[0x55ed884aeade] /usr/libexec/mysqld(+0x671153)[0x55ed884c8153] /usr/libexec/mysqld(+0x666faf)[0x55ed884bdfaf] /usr/libexec/mysqld(+0x668d94)[0x55ed884bfd94] /usr/libexec/mysqld(+0x66a6c7)[0x55ed884c16c7] /usr/libexec/mysqld(+0x60a5a0)[0x55ed884615a0] /usr/libexec/mysqld(+0x60b54b)[0x55ed8846254b] /usr/libexec/mysqld(_Z19ha_commit_one_phaseP3THDb+0x80)[0x55ed882fdac0] /usr/libexec/mysqld(_Z15ha_commit_transP3THDb+0x356)[0x55ed882fe236] /usr/libexec/mysqld(_Z17trans_commit_stmtP3THD+0x1b)[0x55ed882913bb] /usr/libexec/mysqld(_Z21mysql_execute_commandP3THD+0x3dc)[0x55ed881c99ec] /usr/libexec/mysqld(_Z11mysql_parseP3THDPcjP12Parser_state+0x125)[0x55ed881d0445] /usr/libexec/mysqld(_Z16dispatch_command19enum_server_commandP3THDPcj+0x1750)[0x55ed881d24a0] /usr/libexec/mysqld(_Z24do_handle_one_connectionP3THD+0x1c2)[0x55ed88284a22] /usr/libexec/mysqld(handle_one_connection+0x4a)[0x55ed88284aca] pthread_create.c:0(start_thread)[0x7f3d0d473dd5] /lib64/libc.so.6(clone+0x6d)[0x7f3d0bc6cead] Trying to get some variables. Some pointers may be invalid and cause the dump to abort. Query (0x7f3ccc004c18): UPDATE `ipaddresses` SET `lastSeen`='2019-04-24 09:30:01' WHERE `id`='5956' Connection ID (thread ID): 12 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=on,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=off,table_elimination=on,extended_keys=off 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. 190424 09:30:13 mysqld_safe Number of processes running now: 0 190424 09:30:13 mysqld_safe mysqld restarted 190424 9:30:13 [Note] /usr/libexec/mysqld (mysqld 5.5.60-MariaDB) starting as process 20545 ... 190424 9:30:13 InnoDB: The InnoDB memory heap is disabled 190424 9:30:13 InnoDB: Mutexes and rw_locks use GCC atomic builtins 190424 9:30:13 InnoDB: Compressed tables use zlib 1.2.7 190424 9:30:13 InnoDB: Using Linux native AIO 190424 9:30:13 InnoDB: Initializing buffer pool, size = 128.0M 190424 9:30:13 InnoDB: Completed initialization of buffer pool 190424 9:30:13 InnoDB: highest supported file format is Barracuda. 190424 9:30:13 InnoDB: Starting crash recovery from checkpoint LSN=19339923 InnoDB: Restoring possible half-written data pages from the doublewrite buffer... 190424 9:30:13 InnoDB: Starting final batch to recover 2 pages from redo log 190424 9:30:14 InnoDB: Waiting for the background threads to start 190424 9:30:15 Percona XtraDB (http://www.percona.com) 5.5.59-MariaDB-38.11 started; log sequence number 19370392 190424 9:30:15 [Note] Plugin 'FEEDBACK' is disabled. 190424 9:30:15 [Note] Server socket created on IP: '0.0.0.0'. 190424 9:30:15 [Note] Event Scheduler: Loaded 0 events 190424 9:30:15 [Note] /usr/libexec/mysqld: ready for connections. Version: '5.5.60-MariaDB' socket: '/data/mysql/mysql.sock' port: 3306 MariaDB Server 190424 9:45:14 InnoDB: Assertion failure in thread 140555359520512 in file fut0lst.ic line 83 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: http://dev.mysql.com/doc/refman/5.5/en/forcing-innodb-recovery.html InnoDB: about forcing recovery. 190424 9:45:14 [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 http://kb.askmonty.org/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: 5.5.60-MariaDB key_buffer_size=134217728 read_buffer_size=131072 max_used_connections=3 max_threads=153 thread_count=1 It is possible that mysqld could use up to key_buffer_size + (read_buffer_size + sort_buffer_size)*max_threads = 466718 K bytes of memory Hope that's ok; if not, decrease some variables in the equation. Thread pointer: 0x55fdd19d0ab0 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 = 0x7fd598467d80 thread_stack 0x48000 /usr/libexec/mysqld(my_print_stacktrace+0x3d)[0x55fdcebe5cbd] /usr/libexec/mysqld(handle_fatal_signal+0x515)[0x55fdce7fa4a5] sigaction.c:0(__restore_rt)[0x7fd59cb6f5d0] :0(__GI_raise)[0x7fd59b299207] :0(__GI_abort)[0x7fd59b29a8f8] /usr/libexec/mysqld(+0x2d73b7)[0x55fdce62d3b7] /usr/libexec/mysqld(+0x6f87d0)[0x55fdcea4e7d0] /usr/libexec/mysqld(+0x657ade)[0x55fdce9adade] /usr/libexec/mysqld(+0x671153)[0x55fdce9c7153] /usr/libexec/mysqld(+0x666faf)[0x55fdce9bcfaf] /usr/libexec/mysqld(+0x668d94)[0x55fdce9bed94] /usr/libexec/mysqld(+0x66a6c7)[0x55fdce9c06c7] /usr/libexec/mysqld(+0x60a5a0)[0x55fdce9605a0] /usr/libexec/mysqld(+0x60b54b)[0x55fdce96154b] /usr/libexec/mysqld(_Z19ha_commit_one_phaseP3THDb+0x80)[0x55fdce7fcac0] /usr/libexec/mysqld(_Z15ha_commit_transP3THDb+0x356)[0x55fdce7fd236] /usr/libexec/mysqld(_Z17trans_commit_stmtP3THD+0x1b)[0x55fdce7903bb] /usr/libexec/mysqld(_Z21mysql_execute_commandP3THD+0x3dc)[0x55fdce6c89ec] /usr/libexec/mysqld(_Z11mysql_parseP3THDPcjP12Parser_state+0x125)[0x55fdce6cf445] /usr/libexec/mysqld(_Z16dispatch_command19enum_server_commandP3THDPcj+0x1750)[0x55fdce6d14a0] /usr/libexec/mysqld(_Z24do_handle_one_connectionP3THD+0x1c2)[0x55fdce783a22] /usr/libexec/mysqld(handle_one_connection+0x4a)[0x55fdce783aca] pthread_create.c:0(start_thread)[0x7fd59cb67dd5] /lib64/libc.so.6(clone+0x6d)[0x7fd59b360ead] Trying to get some variables. Some pointers may be invalid and cause the dump to abort. Query (0x7fd554004c18): UPDATE `ipaddresses` SET `lastSeen`='2019-04-24 09:45:01' WHERE `id`='5956' Connection ID (thread ID): 12 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=on,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=off,table_elimination=on,extended_keys=off 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. 190424 09:45:14 mysqld_safe Number of processes running now: 0 190424 09:45:14 mysqld_safe mysqld restarted 190424 9:45:14 [Note] /usr/libexec/mysqld (mysqld 5.5.60-MariaDB) starting as process 22145 ... 190424 9:45:14 InnoDB: The InnoDB memory heap is disabled 190424 9:45:14 InnoDB: Mutexes and rw_locks use GCC atomic builtins 190424 9:45:14 InnoDB: Compressed tables use zlib 1.2.7 190424 9:45:14 InnoDB: Using Linux native AIO 190424 9:45:14 InnoDB: Initializing buffer pool, size = 128.0M 190424 9:45:14 InnoDB: Completed initialization of buffer pool 190424 9:45:14 InnoDB: highest supported file format is Barracuda. 190424 9:45:14 InnoDB: Starting crash recovery from checkpoint LSN=19376286 InnoDB: Restoring possible half-written data pages from the doublewrite buffer... 190424 9:45:14 InnoDB: Starting final batch to recover 2 pages from redo log 190424 9:45:15 InnoDB: Waiting for the background threads to start 190424 9:45:16 Percona XtraDB (http://www.percona.com) 5.5.59-MariaDB-38.11 started; log sequence number 19406755 190424 9:45:16 [Note] Plugin 'FEEDBACK' is disabled. 190424 9:45:16 [Note] Server socket created on IP: '0.0.0.0'. 190424 9:45:16 [Note] Event Scheduler: Loaded 0 events 190424 9:45:16 [Note] /usr/libexec/mysqld: ready for connections. Version: '5.5.60-MariaDB' socket: '/data/mysql/mysql.sock' port: 3306 MariaDB Server 190424 10:00:14 InnoDB: Assertion failure in thread 139705523754752 in file fut0lst.ic line 83 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: http://dev.mysql.com/doc/refman/5.5/en/forcing-innodb-recovery.html InnoDB: about forcing recovery. 190424 10:00:14 [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 http://kb.askmonty.org/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: 5.5.60-MariaDB key_buffer_size=134217728 read_buffer_size=131072 max_used_connections=3 max_threads=153 thread_count=1 It is possible that mysqld could use up to key_buffer_size + (read_buffer_size + sort_buffer_size)*max_threads = 466718 K bytes of memory Hope that's ok; if not, decrease some variables in the equation. Thread pointer: 0x55617fabcab0 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 = 0x7f0fba1dcd80 thread_stack 0x48000 /usr/libexec/mysqld(my_print_stacktrace+0x3d)[0x55617c19ccbd] /usr/libexec/mysqld(handle_fatal_signal+0x515)[0x55617bdb14a5] sigaction.c:0(__restore_rt)[0x7f0fd74ef5d0] :0(__GI_raise)[0x7f0fd5c19207] :0(__GI_abort)[0x7f0fd5c1a8f8] /usr/libexec/mysqld(+0x2d73b7)[0x55617bbe43b7] /usr/libexec/mysqld(+0x6f87d0)[0x55617c0057d0] /usr/libexec/mysqld(+0x657ade)[0x55617bf64ade] /usr/libexec/mysqld(+0x671153)[0x55617bf7e153] /usr/libexec/mysqld(+0x666faf)[0x55617bf73faf] /usr/libexec/mysqld(+0x668d94)[0x55617bf75d94] /usr/libexec/mysqld(+0x66a6c7)[0x55617bf776c7] /usr/libexec/mysqld(+0x60a5a0)[0x55617bf175a0] /usr/libexec/mysqld(+0x60b54b)[0x55617bf1854b] /usr/libexec/mysqld(_Z19ha_commit_one_phaseP3THDb+0x80)[0x55617bdb3ac0] /usr/libexec/mysqld(_Z15ha_commit_transP3THDb+0x356)[0x55617bdb4236] /usr/libexec/mysqld(_Z17trans_commit_stmtP3THD+0x1b)[0x55617bd473bb] /usr/libexec/mysqld(_Z21mysql_execute_commandP3THD+0x3dc)[0x55617bc7f9ec] /usr/libexec/mysqld(_Z11mysql_parseP3THDPcjP12Parser_state+0x125)[0x55617bc86445] /usr/libexec/mysqld(_Z16dispatch_command19enum_server_commandP3THDPcj+0x1750)[0x55617bc884a0] /usr/libexec/mysqld(_Z24do_handle_one_connectionP3THD+0x1c2)[0x55617bd3aa22] /usr/libexec/mysqld(handle_one_connection+0x4a)[0x55617bd3aaca] pthread_create.c:0(start_thread)[0x7f0fd74e7dd5] /lib64/libc.so.6(clone+0x6d)[0x7f0fd5ce0ead] Trying to get some variables. Some pointers may be invalid and cause the dump to abort. Query (0x7f0f90004c18): UPDATE `ipaddresses` SET `lastSeen`='2019-04-24 10:00:01' WHERE `id`='5956' Connection ID (thread ID): 12 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=on,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=off,table_elimination=on,extended_keys=off 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. 190424 10:00:14 mysqld_safe Number of processes running now: 0 190424 10:00:14 mysqld_safe mysqld restarted 190424 10:00:14 [Note] /usr/libexec/mysqld (mysqld 5.5.60-MariaDB) starting as process 24166 ... 190424 10:00:14 InnoDB: The InnoDB memory heap is disabled 190424 10:00:14 InnoDB: Mutexes and rw_locks use GCC atomic builtins 190424 10:00:14 InnoDB: Compressed tables use zlib 1.2.7 190424 10:00:14 InnoDB: Using Linux native AIO 190424 10:00:14 InnoDB: Initializing buffer pool, size = 128.0M 190424 10:00:14 InnoDB: Completed initialization of buffer pool 190424 10:00:14 InnoDB: highest supported file format is Barracuda. 190424 10:00:14 InnoDB: Starting crash recovery from checkpoint LSN=19412771 InnoDB: Restoring possible half-written data pages from the doublewrite buffer... 190424 10:00:14 InnoDB: Starting final batch to recover 3 pages from redo log 190424 10:00:15 InnoDB: Waiting for the background threads to start 190424 10:00:16 Percona XtraDB (http://www.percona.com) 5.5.59-MariaDB-38.11 started; log sequence number 19444003 190424 10:00:16 [Note] Plugin 'FEEDBACK' is disabled. 190424 10:00:16 [Note] Server socket created on IP: '0.0.0.0'. 190424 10:00:16 [Note] Event Scheduler: Loaded 0 events 190424 10:00:16 [Note] /usr/libexec/mysqld: ready for connections. Version: '5.5.60-MariaDB' socket: '/data/mysql/mysql.sock' port: 3306 MariaDB Server 190424 10:15:13 InnoDB: Assertion failure in thread 140287796446976 in file fut0lst.ic line 83 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: http://dev.mysql.com/doc/refman/5.5/en/forcing-innodb-recovery.html InnoDB: about forcing recovery. 190424 10:15:13 [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 http://kb.askmonty.org/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: 5.5.60-MariaDB key_buffer_size=134217728 read_buffer_size=131072 max_used_connections=3 max_threads=153 thread_count=1 It is possible that mysqld could use up to key_buffer_size + (read_buffer_size + sort_buffer_size)*max_threads = 466718 K bytes of memory Hope that's ok; if not, decrease some variables in the equation. Thread pointer: 0x5573ecb938f0 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 = 0x7f974c45fd80 thread_stack 0x48000 /usr/libexec/mysqld(my_print_stacktrace+0x3d)[0x5573ea055cbd] /usr/libexec/mysqld(handle_fatal_signal+0x515)[0x5573e9c6a4a5] sigaction.c:0(__restore_rt)[0x7f9751abe5d0] :0(__GI_raise)[0x7f97501e8207] :0(__GI_abort)[0x7f97501e98f8] /usr/libexec/mysqld(+0x2d73b7)[0x5573e9a9d3b7] /usr/libexec/mysqld(+0x6f87d0)[0x5573e9ebe7d0] /usr/libexec/mysqld(+0x657ade)[0x5573e9e1dade] /usr/libexec/mysqld(+0x671153)[0x5573e9e37153] /usr/libexec/mysqld(+0x666faf)[0x5573e9e2cfaf] /usr/libexec/mysqld(+0x668d94)[0x5573e9e2ed94] /usr/libexec/mysqld(+0x66a6c7)[0x5573e9e306c7] /usr/libexec/mysqld(+0x60a5a0)[0x5573e9dd05a0] /usr/libexec/mysqld(+0x60b54b)[0x5573e9dd154b] /usr/libexec/mysqld(_Z19ha_commit_one_phaseP3THDb+0x80)[0x5573e9c6cac0] /usr/libexec/mysqld(_Z15ha_commit_transP3THDb+0x356)[0x5573e9c6d236] /usr/libexec/mysqld(_Z17trans_commit_stmtP3THD+0x1b)[0x5573e9c003bb] /usr/libexec/mysqld(_Z21mysql_execute_commandP3THD+0x3dc)[0x5573e9b389ec] /usr/libexec/mysqld(_Z11mysql_parseP3THDPcjP12Parser_state+0x125)[0x5573e9b3f445] /usr/libexec/mysqld(_Z16dispatch_command19enum_server_commandP3THDPcj+0x1750)[0x5573e9b414a0] /usr/libexec/mysqld(_Z24do_handle_one_connectionP3THD+0x1c2)[0x5573e9bf3a22] /usr/libexec/mysqld(handle_one_connection+0x4a)[0x5573e9bf3aca] pthread_create.c:0(start_thread)[0x7f9751ab6dd5] /lib64/libc.so.6(clone+0x6d)[0x7f97502afead] Trying to get some variables. Some pointers may be invalid and cause the dump to abort. Query (0x7f970c004c18): UPDATE `ipaddresses` SET `lastSeen`='2019-04-24 10:15:01' WHERE `id`='5956' Connection ID (thread ID): 12 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=on,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=off,table_elimination=on,extended_keys=off 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. 190424 10:15:13 mysqld_safe Number of processes running now: 0 190424 10:15:13 mysqld_safe mysqld restarted 190424 10:15:13 [Note] /usr/libexec/mysqld (mysqld 5.5.60-MariaDB) starting as process 25733 ... 190424 10:15:13 InnoDB: The InnoDB memory heap is disabled 190424 10:15:13 InnoDB: Mutexes and rw_locks use GCC atomic builtins 190424 10:15:13 InnoDB: Compressed tables use zlib 1.2.7 190424 10:15:13 InnoDB: Using Linux native AIO 190424 10:15:13 InnoDB: Initializing buffer pool, size = 128.0M 190424 10:15:13 InnoDB: Completed initialization of buffer pool 190424 10:15:13 InnoDB: highest supported file format is Barracuda. 190424 10:15:13 InnoDB: Starting crash recovery from checkpoint LSN=19450002 InnoDB: Restoring possible half-written data pages from the doublewrite buffer... 190424 10:15:13 InnoDB: Starting final batch to recover 3 pages from redo log 190424 10:15:14 InnoDB: Waiting for the background threads to start 190424 10:15:15 Percona XtraDB (http://www.percona.com) 5.5.59-MariaDB-38.11 started; log sequence number 19481234 190424 10:15:15 [Note] Plugin 'FEEDBACK' is disabled. 190424 10:15:15 [Note] Server socket created on IP: '0.0.0.0'. 190424 10:15:15 [Note] Event Scheduler: Loaded 0 events 190424 10:15:15 [Note] /usr/libexec/mysqld: ready for connections. Version: '5.5.60-MariaDB' socket: '/data/mysql/mysql.sock' port: 3306 MariaDB Server 190424 10:30:13 InnoDB: Assertion failure in thread 140519590299392 in file fut0lst.ic line 83 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: http://dev.mysql.com/doc/refman/5.5/en/forcing-innodb-recovery.html InnoDB: about forcing recovery. 190424 10:30:13 [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 http://kb.askmonty.org/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: 5.5.60-MariaDB key_buffer_size=134217728 read_buffer_size=131072 max_used_connections=3 max_threads=153 thread_count=1 It is possible that mysqld could use up to key_buffer_size + (read_buffer_size + sort_buffer_size)*max_threads = 466718 K bytes of memory Hope that's ok; if not, decrease some variables in the equation. Thread pointer: 0x55affdd968f0 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 = 0x7fcd44437d80 thread_stack 0x48000 /usr/libexec/mysqld(my_print_stacktrace+0x3d)[0x55affb9cdcbd] /usr/libexec/mysqld(handle_fatal_signal+0x515)[0x55affb5e24a5] sigaction.c:0(__restore_rt)[0x7fcd4a2975d0] :0(__GI_raise)[0x7fcd489c1207] :0(__GI_abort)[0x7fcd489c28f8] /usr/libexec/mysqld(+0x2d73b7)[0x55affb4153b7] /usr/libexec/mysqld(+0x6f87d0)[0x55affb8367d0] /usr/libexec/mysqld(+0x657ade)[0x55affb795ade] /usr/libexec/mysqld(+0x671153)[0x55affb7af153] /usr/libexec/mysqld(+0x666faf)[0x55affb7a4faf] /usr/libexec/mysqld(+0x668d94)[0x55affb7a6d94] /usr/libexec/mysqld(+0x66a6c7)[0x55affb7a86c7] /usr/libexec/mysqld(+0x60a5a0)[0x55affb7485a0] /usr/libexec/mysqld(+0x60b54b)[0x55affb74954b] /usr/libexec/mysqld(_Z19ha_commit_one_phaseP3THDb+0x80)[0x55affb5e4ac0] /usr/libexec/mysqld(_Z15ha_commit_transP3THDb+0x356)[0x55affb5e5236] /usr/libexec/mysqld(_Z17trans_commit_stmtP3THD+0x1b)[0x55affb5783bb] /usr/libexec/mysqld(_Z21mysql_execute_commandP3THD+0x3dc)[0x55affb4b09ec] /usr/libexec/mysqld(_Z11mysql_parseP3THDPcjP12Parser_state+0x125)[0x55affb4b7445] /usr/libexec/mysqld(_Z16dispatch_command19enum_server_commandP3THDPcj+0x1750)[0x55affb4b94a0] /usr/libexec/mysqld(_Z24do_handle_one_connectionP3THD+0x1c2)[0x55affb56ba22] /usr/libexec/mysqld(handle_one_connection+0x4a)[0x55affb56baca] pthread_create.c:0(start_thread)[0x7fcd4a28fdd5] /lib64/libc.so.6(clone+0x6d)[0x7fcd48a88ead] Trying to get some variables. Some pointers may be invalid and cause the dump to abort. Query (0x7fcd04004c18): UPDATE `ipaddresses` SET `lastSeen`='2019-04-24 10:30:01' WHERE `id`='5956' Connection ID (thread ID): 12 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=on,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=off,table_elimination=on,extended_keys=off 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. 190424 10:30:13 mysqld_safe Number of processes running now: 0 190424 10:30:13 mysqld_safe mysqld restarted 190424 10:30:13 [Note] /usr/libexec/mysqld (mysqld 5.5.60-MariaDB) starting as process 27760 ... 190424 10:30:13 InnoDB: The InnoDB memory heap is disabled 190424 10:30:13 InnoDB: Mutexes and rw_locks use GCC atomic builtins 190424 10:30:13 InnoDB: Compressed tables use zlib 1.2.7 190424 10:30:13 InnoDB: Using Linux native AIO 190424 10:30:13 InnoDB: Initializing buffer pool, size = 128.0M 190424 10:30:13 InnoDB: Completed initialization of buffer pool 190424 10:30:13 InnoDB: highest supported file format is Barracuda. 190424 10:30:13 InnoDB: Starting crash recovery from checkpoint LSN=19487218 InnoDB: Restoring possible half-written data pages from the doublewrite buffer... 190424 10:30:13 InnoDB: Starting final batch to recover 3 pages from redo log 190424 10:30:14 InnoDB: Waiting for the background threads to start 190424 10:30:15 Percona XtraDB (http://www.percona.com) 5.5.59-MariaDB-38.11 started; log sequence number 19518501 190424 10:30:15 [Note] Plugin 'FEEDBACK' is disabled. 190424 10:30:15 [Note] Server socket created on IP: '0.0.0.0'. 190424 10:30:15 [Note] Event Scheduler: Loaded 0 events 190424 10:30:15 [Note] /usr/libexec/mysqld: ready for connections. Version: '5.5.60-MariaDB' socket: '/data/mysql/mysql.sock' port: 3306 MariaDB Server 190424 10:45:14 InnoDB: Assertion failure in thread 140336196073216 in file fut0lst.ic line 83 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: http://dev.mysql.com/doc/refman/5.5/en/forcing-innodb-recovery.html InnoDB: about forcing recovery. 190424 10:45:14 [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 http://kb.askmonty.org/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: 5.5.60-MariaDB key_buffer_size=134217728 read_buffer_size=131072 max_used_connections=3 max_threads=153 thread_count=1 It is possible that mysqld could use up to key_buffer_size + (read_buffer_size + sort_buffer_size)*max_threads = 466718 K bytes of memory Hope that's ok; if not, decrease some variables in the equation. Thread pointer: 0x55fa0eb9e570 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 = 0x7fa2911dad80 thread_stack 0x48000 /usr/libexec/mysqld(my_print_stacktrace+0x3d)[0x55fa0cebbcbd] /usr/libexec/mysqld(handle_fatal_signal+0x515)[0x55fa0cad04a5] sigaction.c:0(__restore_rt)[0x7fa2ae5115d0] :0(__GI_raise)[0x7fa2acc3b207] :0(__GI_abort)[0x7fa2acc3c8f8] /usr/libexec/mysqld(+0x2d73b7)[0x55fa0c9033b7] /usr/libexec/mysqld(+0x6f87d0)[0x55fa0cd247d0] /usr/libexec/mysqld(+0x657ade)[0x55fa0cc83ade] /usr/libexec/mysqld(+0x671153)[0x55fa0cc9d153] /usr/libexec/mysqld(+0x666faf)[0x55fa0cc92faf] /usr/libexec/mysqld(+0x668d94)[0x55fa0cc94d94] /usr/libexec/mysqld(+0x66a6c7)[0x55fa0cc966c7] /usr/libexec/mysqld(+0x60a5a0)[0x55fa0cc365a0] /usr/libexec/mysqld(+0x60b54b)[0x55fa0cc3754b] /usr/libexec/mysqld(_Z19ha_commit_one_phaseP3THDb+0x80)[0x55fa0cad2ac0] /usr/libexec/mysqld(_Z15ha_commit_transP3THDb+0x356)[0x55fa0cad3236] /usr/libexec/mysqld(_Z17trans_commit_stmtP3THD+0x1b)[0x55fa0ca663bb] /usr/libexec/mysqld(_Z21mysql_execute_commandP3THD+0x3dc)[0x55fa0c99e9ec] /usr/libexec/mysqld(_Z11mysql_parseP3THDPcjP12Parser_state+0x125)[0x55fa0c9a5445] /usr/libexec/mysqld(_Z16dispatch_command19enum_server_commandP3THDPcj+0x1750)[0x55fa0c9a74a0] /usr/libexec/mysqld(_Z24do_handle_one_connectionP3THD+0x1c2)[0x55fa0ca59a22] /usr/libexec/mysqld(handle_one_connection+0x4a)[0x55fa0ca59aca] pthread_create.c:0(start_thread)[0x7fa2ae509dd5] /lib64/libc.so.6(clone+0x6d)[0x7fa2acd02ead] Trying to get some variables. Some pointers may be invalid and cause the dump to abort. Query (0x7fa268004c18): UPDATE `ipaddresses` SET `lastSeen`='2019-04-24 10:45:01' WHERE `id`='5956' Connection ID (thread ID): 12 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=on,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=off,table_elimination=on,extended_keys=off 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. 190424 10:45:14 mysqld_safe Number of processes running now: 0 190424 10:45:14 mysqld_safe mysqld restarted 190424 10:45:14 [Note] /usr/libexec/mysqld (mysqld 5.5.60-MariaDB) starting as process 29316 ... 190424 10:45:14 InnoDB: The InnoDB memory heap is disabled 190424 10:45:14 InnoDB: Mutexes and rw_locks use GCC atomic builtins 190424 10:45:14 InnoDB: Compressed tables use zlib 1.2.7 190424 10:45:14 InnoDB: Using Linux native AIO 190424 10:45:14 InnoDB: Initializing buffer pool, size = 128.0M 190424 10:45:14 InnoDB: Completed initialization of buffer pool 190424 10:45:14 InnoDB: highest supported file format is Barracuda. 190424 10:45:14 InnoDB: Starting crash recovery from checkpoint LSN=19526372 InnoDB: Restoring possible half-written data pages from the doublewrite buffer... 190424 10:45:14 InnoDB: Starting final batch to recover 3 pages from redo log 190424 10:45:14 InnoDB: Waiting for the background threads to start 190424 10:45:15 Percona XtraDB (http://www.percona.com) 5.5.59-MariaDB-38.11 started; log sequence number 19559802 190424 10:45:16 [Note] Plugin 'FEEDBACK' is disabled. 190424 10:45:16 [Note] Server socket created on IP: '0.0.0.0'. 190424 10:45:16 [Note] Event Scheduler: Loaded 0 events 190424 10:45:16 [Note] /usr/libexec/mysqld: ready for connections. Version: '5.5.60-MariaDB' socket: '/data/mysql/mysql.sock' port: 3306 MariaDB Server 190424 11:00:13 InnoDB: Assertion failure in thread 139732939384576 in file fut0lst.ic line 83 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: http://dev.mysql.com/doc/refman/5.5/en/forcing-innodb-recovery.html InnoDB: about forcing recovery. 190424 11:00:13 [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 http://kb.askmonty.org/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: 5.5.60-MariaDB key_buffer_size=134217728 read_buffer_size=131072 max_used_connections=3 max_threads=153 thread_count=1 It is possible that mysqld could use up to key_buffer_size + (read_buffer_size + sort_buffer_size)*max_threads = 466718 K bytes of memory Hope that's ok; if not, decrease some variables in the equation. Thread pointer: 0x55f967b91b30 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 = 0x7f161c371d80 thread_stack 0x48000 /usr/libexec/mysqld(my_print_stacktrace+0x3d)[0x55f9653e7cbd] /usr/libexec/mysqld(handle_fatal_signal+0x515)[0x55f964ffc4a5] sigaction.c:0(__restore_rt)[0x7f1622fc05d0] :0(__GI_raise)[0x7f16216ea207] :0(__GI_abort)[0x7f16216eb8f8] /usr/libexec/mysqld(+0x2d73b7)[0x55f964e2f3b7] /usr/libexec/mysqld(+0x6f87d0)[0x55f9652507d0] /usr/libexec/mysqld(+0x657ade)[0x55f9651afade] /usr/libexec/mysqld(+0x671153)[0x55f9651c9153] /usr/libexec/mysqld(+0x666faf)[0x55f9651befaf] /usr/libexec/mysqld(+0x668d94)[0x55f9651c0d94] /usr/libexec/mysqld(+0x66a6c7)[0x55f9651c26c7] /usr/libexec/mysqld(+0x60a5a0)[0x55f9651625a0] /usr/libexec/mysqld(+0x60b54b)[0x55f96516354b] /usr/libexec/mysqld(_Z19ha_commit_one_phaseP3THDb+0x80)[0x55f964ffeac0] /usr/libexec/mysqld(_Z15ha_commit_transP3THDb+0x356)[0x55f964fff236] /usr/libexec/mysqld(_Z17trans_commit_stmtP3THD+0x1b)[0x55f964f923bb] /usr/libexec/mysqld(_Z21mysql_execute_commandP3THD+0x3dc)[0x55f964eca9ec] /usr/libexec/mysqld(_Z11mysql_parseP3THDPcjP12Parser_state+0x125)[0x55f964ed1445] /usr/libexec/mysqld(_Z16dispatch_command19enum_server_commandP3THDPcj+0x1750)[0x55f964ed34a0] /usr/libexec/mysqld(_Z24do_handle_one_connectionP3THD+0x1c2)[0x55f964f85a22] /usr/libexec/mysqld(handle_one_connection+0x4a)[0x55f964f85aca] pthread_create.c:0(start_thread)[0x7f1622fb8dd5] /lib64/libc.so.6(clone+0x6d)[0x7f16217b1ead] Trying to get some variables. Some pointers may be invalid and cause the dump to abort. Query (0x7f15dc004c18): UPDATE `ipaddresses` SET `lastSeen`='2019-04-24 11:00:01' WHERE `id`='5956' Connection ID (thread ID): 12 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=on,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=off,table_elimination=on,extended_keys=off 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. 190424 11:00:13 mysqld_safe Number of processes running now: 0 190424 11:00:13 mysqld_safe mysqld restarted 190424 11:00:13 [Note] /usr/libexec/mysqld (mysqld 5.5.60-MariaDB) starting as process 31346 ... 190424 11:00:14 InnoDB: The InnoDB memory heap is disabled 190424 11:00:14 InnoDB: Mutexes and rw_locks use GCC atomic builtins 190424 11:00:14 InnoDB: Compressed tables use zlib 1.2.7 190424 11:00:14 InnoDB: Using Linux native AIO 190424 11:00:14 InnoDB: Initializing buffer pool, size = 128.0M 190424 11:00:14 InnoDB: Completed initialization of buffer pool 190424 11:00:14 InnoDB: highest supported file format is Barracuda. 190424 11:00:14 InnoDB: Starting crash recovery from checkpoint LSN=19565911 InnoDB: Restoring possible half-written data pages from the doublewrite buffer... 190424 11:00:14 InnoDB: Starting final batch to recover 2 pages from redo log 190424 11:00:14 InnoDB: Waiting for the background threads to start 190424 11:00:15 Percona XtraDB (http://www.percona.com) 5.5.59-MariaDB-38.11 started; log sequence number 19596395 190424 11:00:15 [Note] Plugin 'FEEDBACK' is disabled. 190424 11:00:15 [Note] Server socket created on IP: '0.0.0.0'. 190424 11:00:15 [Note] Event Scheduler: Loaded 0 events 190424 11:00:15 [Note] /usr/libexec/mysqld: ready for connections. Version: '5.5.60-MariaDB' socket: '/data/mysql/mysql.sock' port: 3306 MariaDB Server 190424 11:15:14 InnoDB: Assertion failure in thread 140090223732480 in file fut0lst.ic line 83 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: http://dev.mysql.com/doc/refman/5.5/en/forcing-innodb-recovery.html InnoDB: about forcing recovery. 190424 11:15:14 [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 http://kb.askmonty.org/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: 5.5.60-MariaDB key_buffer_size=134217728 read_buffer_size=131072 max_used_connections=3 max_threads=153 thread_count=1 It is possible that mysqld could use up to key_buffer_size + (read_buffer_size + sort_buffer_size)*max_threads = 466718 K bytes of memory Hope that's ok; if not, decrease some variables in the equation. Thread pointer: 0x562a446f7ab0 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 = 0x7f694c059d80 thread_stack 0x48000 /usr/libexec/mysqld(my_print_stacktrace+0x3d)[0x562a41c36cbd] /usr/libexec/mysqld(handle_fatal_signal+0x515)[0x562a4184b4a5] sigaction.c:0(__restore_rt)[0x7f6951d2e5d0] :0(__GI_raise)[0x7f6950458207] :0(__GI_abort)[0x7f69504598f8] /usr/libexec/mysqld(+0x2d73b7)[0x562a4167e3b7] /usr/libexec/mysqld(+0x6f87d0)[0x562a41a9f7d0] /usr/libexec/mysqld(+0x657ade)[0x562a419feade] /usr/libexec/mysqld(+0x671153)[0x562a41a18153] /usr/libexec/mysqld(+0x666faf)[0x562a41a0dfaf] /usr/libexec/mysqld(+0x668d94)[0x562a41a0fd94] /usr/libexec/mysqld(+0x66a6c7)[0x562a41a116c7] /usr/libexec/mysqld(+0x60a5a0)[0x562a419b15a0] /usr/libexec/mysqld(+0x60b54b)[0x562a419b254b] /usr/libexec/mysqld(_Z19ha_commit_one_phaseP3THDb+0x80)[0x562a4184dac0] /usr/libexec/mysqld(_Z15ha_commit_transP3THDb+0x356)[0x562a4184e236] /usr/libexec/mysqld(_Z17trans_commit_stmtP3THD+0x1b)[0x562a417e13bb] /usr/libexec/mysqld(_Z21mysql_execute_commandP3THD+0x3dc)[0x562a417199ec] /usr/libexec/mysqld(_Z11mysql_parseP3THDPcjP12Parser_state+0x125)[0x562a41720445] /usr/libexec/mysqld(_Z16dispatch_command19enum_server_commandP3THDPcj+0x1750)[0x562a417224a0] /usr/libexec/mysqld(_Z24do_handle_one_connectionP3THD+0x1c2)[0x562a417d4a22] /usr/libexec/mysqld(handle_one_connection+0x4a)[0x562a417d4aca] pthread_create.c:0(start_thread)[0x7f6951d26dd5] /lib64/libc.so.6(clone+0x6d)[0x7f695051fead] Trying to get some variables. Some pointers may be invalid and cause the dump to abort. Query (0x7f690c004c18): UPDATE `ipaddresses` SET `lastSeen`='2019-04-24 11:15:02' WHERE `id`='5956' Connection ID (thread ID): 12 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=on,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=off,table_elimination=on,extended_keys=off 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. 190424 11:15:14 mysqld_safe Number of processes running now: 0 190424 11:15:14 mysqld_safe mysqld restarted 190424 11:15:14 [Note] /usr/libexec/mysqld (mysqld 5.5.60-MariaDB) starting as process 449 ... 190424 11:15:14 InnoDB: The InnoDB memory heap is disabled 190424 11:15:14 InnoDB: Mutexes and rw_locks use GCC atomic builtins 190424 11:15:14 InnoDB: Compressed tables use zlib 1.2.7 190424 11:15:14 InnoDB: Using Linux native AIO 190424 11:15:14 InnoDB: Initializing buffer pool, size = 128.0M 190424 11:15:14 InnoDB: Completed initialization of buffer pool 190424 11:15:14 InnoDB: highest supported file format is Barracuda. 190424 11:15:14 InnoDB: Starting crash recovery from checkpoint LSN=19602273 InnoDB: Restoring possible half-written data pages from the doublewrite buffer... 190424 11:15:14 InnoDB: Starting final batch to recover 2 pages from redo log 190424 11:15:15 InnoDB: Waiting for the background threads to start 190424 11:15:16 Percona XtraDB (http://www.percona.com) 5.5.59-MariaDB-38.11 started; log sequence number 19632758 190424 11:15:16 [Note] Plugin 'FEEDBACK' is disabled. 190424 11:15:16 [Note] Server socket created on IP: '0.0.0.0'. 190424 11:15:16 [Note] Event Scheduler: Loaded 0 events 190424 11:15:16 [Note] /usr/libexec/mysqld: ready for connections. Version: '5.5.60-MariaDB' socket: '/data/mysql/mysql.sock' port: 3306 MariaDB Server 190424 11:30:13 InnoDB: Assertion failure in thread 140324676372224 in file fut0lst.ic line 83 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: http://dev.mysql.com/doc/refman/5.5/en/forcing-innodb-recovery.html InnoDB: about forcing recovery. 190424 11:30:13 [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 http://kb.askmonty.org/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: 5.5.60-MariaDB key_buffer_size=134217728 read_buffer_size=131072 max_used_connections=3 max_threads=153 thread_count=1 It is possible that mysqld could use up to key_buffer_size + (read_buffer_size + sort_buffer_size)*max_threads = 466718 K bytes of memory Hope that's ok; if not, decrease some variables in the equation. Thread pointer: 0x55ef7aa05ab0 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 = 0x7f9fe27cfd80 thread_stack 0x48000 /usr/libexec/mysqld(my_print_stacktrace+0x3d)[0x55ef77d12cbd] /usr/libexec/mysqld(handle_fatal_signal+0x515)[0x55ef779274a5] sigaction.c:0(__restore_rt)[0x7f9fffa8b5d0] :0(__GI_raise)[0x7f9ffe1b5207] :0(__GI_abort)[0x7f9ffe1b68f8] /usr/libexec/mysqld(+0x2d73b7)[0x55ef7775a3b7] /usr/libexec/mysqld(+0x6f87d0)[0x55ef77b7b7d0] /usr/libexec/mysqld(+0x657ade)[0x55ef77adaade] /usr/libexec/mysqld(+0x671153)[0x55ef77af4153] /usr/libexec/mysqld(+0x666faf)[0x55ef77ae9faf] /usr/libexec/mysqld(+0x668d94)[0x55ef77aebd94] /usr/libexec/mysqld(+0x66a6c7)[0x55ef77aed6c7] /usr/libexec/mysqld(+0x60a5a0)[0x55ef77a8d5a0] /usr/libexec/mysqld(+0x60b54b)[0x55ef77a8e54b] /usr/libexec/mysqld(_Z19ha_commit_one_phaseP3THDb+0x80)[0x55ef77929ac0] /usr/libexec/mysqld(_Z15ha_commit_transP3THDb+0x356)[0x55ef7792a236] /usr/libexec/mysqld(_Z17trans_commit_stmtP3THD+0x1b)[0x55ef778bd3bb] /usr/libexec/mysqld(_Z21mysql_execute_commandP3THD+0x3dc)[0x55ef777f59ec] /usr/libexec/mysqld(_Z11mysql_parseP3THDPcjP12Parser_state+0x125)[0x55ef777fc445] /usr/libexec/mysqld(_Z16dispatch_command19enum_server_commandP3THDPcj+0x1750)[0x55ef777fe4a0] /usr/libexec/mysqld(_Z24do_handle_one_connectionP3THD+0x1c2)[0x55ef778b0a22] /usr/libexec/mysqld(handle_one_connection+0x4a)[0x55ef778b0aca] pthread_create.c:0(start_thread)[0x7f9fffa83dd5] /lib64/libc.so.6(clone+0x6d)[0x7f9ffe27cead] Trying to get some variables. Some pointers may be invalid and cause the dump to abort. Query (0x7f9fb8004c18): UPDATE `ipaddresses` SET `lastSeen`='2019-04-24 11:30:01' WHERE `id`='5956' Connection ID (thread ID): 12 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=on,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=off,table_elimination=on,extended_keys=off 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. 190424 11:30:14 mysqld_safe Number of processes running now: 0 190424 11:30:14 mysqld_safe mysqld restarted 190424 11:30:14 [Note] /usr/libexec/mysqld (mysqld 5.5.60-MariaDB) starting as process 2511 ... 190424 11:30:14 InnoDB: The InnoDB memory heap is disabled 190424 11:30:14 InnoDB: Mutexes and rw_locks use GCC atomic builtins 190424 11:30:14 InnoDB: Compressed tables use zlib 1.2.7 190424 11:30:14 InnoDB: Using Linux native AIO 190424 11:30:14 InnoDB: Initializing buffer pool, size = 128.0M 190424 11:30:14 InnoDB: Completed initialization of buffer pool 190424 11:30:14 InnoDB: highest supported file format is Barracuda. 190424 11:30:14 InnoDB: Starting crash recovery from checkpoint LSN=19638636 InnoDB: Restoring possible half-written data pages from the doublewrite buffer... 190424 11:30:14 InnoDB: Starting final batch to recover 2 pages from redo log 190424 11:30:14 InnoDB: Waiting for the background threads to start 190424 11:30:15 Percona XtraDB (http://www.percona.com) 5.5.59-MariaDB-38.11 started; log sequence number 19669137 190424 11:30:15 [Note] Plugin 'FEEDBACK' is disabled. 190424 11:30:15 [Note] Server socket created on IP: '0.0.0.0'. 190424 11:30:15 [Note] Event Scheduler: Loaded 0 events 190424 11:30:15 [Note] /usr/libexec/mysqld: ready for connections. Version: '5.5.60-MariaDB' socket: '/data/mysql/mysql.sock' port: 3306 MariaDB Server 190424 11:45:13 InnoDB: Assertion failure in thread 140112171595520 in file fut0lst.ic line 83 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: http://dev.mysql.com/doc/refman/5.5/en/forcing-innodb-recovery.html InnoDB: about forcing recovery. 190424 11:45:13 [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 http://kb.askmonty.org/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: 5.5.60-MariaDB key_buffer_size=134217728 read_buffer_size=131072 max_used_connections=3 max_threads=153 thread_count=1 It is possible that mysqld could use up to key_buffer_size + (read_buffer_size + sort_buffer_size)*max_threads = 466718 K bytes of memory Hope that's ok; if not, decrease some variables in the equation. Thread pointer: 0x562a1b0028f0 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 = 0x7f6e68376d80 thread_stack 0x48000 /usr/libexec/mysqld(my_print_stacktrace+0x3d)[0x562a1946ccbd] /usr/libexec/mysqld(handle_fatal_signal+0x515)[0x562a190814a5] sigaction.c:0(__restore_rt)[0x7f6e6dfc35d0] :0(__GI_raise)[0x7f6e6c6ed207] :0(__GI_abort)[0x7f6e6c6ee8f8] /usr/libexec/mysqld(+0x2d73b7)[0x562a18eb43b7] /usr/libexec/mysqld(+0x6f87d0)[0x562a192d57d0] /usr/libexec/mysqld(+0x657ade)[0x562a19234ade] /usr/libexec/mysqld(+0x671153)[0x562a1924e153] /usr/libexec/mysqld(+0x666faf)[0x562a19243faf] /usr/libexec/mysqld(+0x668d94)[0x562a19245d94] /usr/libexec/mysqld(+0x66a6c7)[0x562a192476c7] /usr/libexec/mysqld(+0x60a5a0)[0x562a191e75a0] /usr/libexec/mysqld(+0x60b54b)[0x562a191e854b] /usr/libexec/mysqld(_Z19ha_commit_one_phaseP3THDb+0x80)[0x562a19083ac0] /usr/libexec/mysqld(_Z15ha_commit_transP3THDb+0x356)[0x562a19084236] /usr/libexec/mysqld(_Z17trans_commit_stmtP3THD+0x1b)[0x562a190173bb] /usr/libexec/mysqld(_Z21mysql_execute_commandP3THD+0x3dc)[0x562a18f4f9ec] /usr/libexec/mysqld(_Z11mysql_parseP3THDPcjP12Parser_state+0x125)[0x562a18f56445] /usr/libexec/mysqld(_Z16dispatch_command19enum_server_commandP3THDPcj+0x1750)[0x562a18f584a0] /usr/libexec/mysqld(_Z24do_handle_one_connectionP3THD+0x1c2)[0x562a1900aa22] /usr/libexec/mysqld(handle_one_connection+0x4a)[0x562a1900aaca] pthread_create.c:0(start_thread)[0x7f6e6dfbbdd5] /lib64/libc.so.6(clone+0x6d)[0x7f6e6c7b4ead] Trying to get some variables. Some pointers may be invalid and cause the dump to abort. Query (0x7f6e28004c18): UPDATE `ipaddresses` SET `lastSeen`='2019-04-24 11:45:01' WHERE `id`='5956' Connection ID (thread ID): 12 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=on,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=off,table_elimination=on,extended_keys=off 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. 190424 11:45:13 mysqld_safe Number of processes running now: 0 190424 11:45:13 mysqld_safe mysqld restarted 190424 11:45:13 [Note] /usr/libexec/mysqld (mysqld 5.5.60-MariaDB) starting as process 4083 ... 190424 11:45:13 InnoDB: The InnoDB memory heap is disabled 190424 11:45:13 InnoDB: Mutexes and rw_locks use GCC atomic builtins 190424 11:45:13 InnoDB: Compressed tables use zlib 1.2.7 190424 11:45:13 InnoDB: Using Linux native AIO 190424 11:45:13 InnoDB: Initializing buffer pool, size = 128.0M 190424 11:45:13 InnoDB: Completed initialization of buffer pool 190424 11:45:13 InnoDB: highest supported file format is Barracuda. 190424 11:45:13 InnoDB: Starting crash recovery from checkpoint LSN=19675868 InnoDB: Restoring possible half-written data pages from the doublewrite buffer... 190424 11:45:13 InnoDB: Starting final batch to recover 2 pages from redo log 190424 11:45:14 InnoDB: Waiting for the background threads to start 190424 11:45:15 Percona XtraDB (http://www.percona.com) 5.5.59-MariaDB-38.11 started; log sequence number 19706386 190424 11:45:15 [Note] Plugin 'FEEDBACK' is disabled. 190424 11:45:15 [Note] Server socket created on IP: '0.0.0.0'. 190424 11:45:15 [Note] Event Scheduler: Loaded 0 events 190424 11:45:15 [Note] /usr/libexec/mysqld: ready for connections. Version: '5.5.60-MariaDB' socket: '/data/mysql/mysql.sock' port: 3306 MariaDB Server 190424 12:00:14 InnoDB: Assertion failure in thread 139953692030720 in file fut0lst.ic line 83 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: http://dev.mysql.com/doc/refman/5.5/en/forcing-innodb-recovery.html InnoDB: about forcing recovery. 190424 12:00:14 [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 http://kb.askmonty.org/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: 5.5.60-MariaDB key_buffer_size=134217728 read_buffer_size=131072 max_used_connections=3 max_threads=153 thread_count=1 It is possible that mysqld could use up to key_buffer_size + (read_buffer_size + sort_buffer_size)*max_threads = 466718 K bytes of memory Hope that's ok; if not, decrease some variables in the equation. Thread pointer: 0x558489375730 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 = 0x7f4982192d80 thread_stack 0x48000 /usr/libexec/mysqld(my_print_stacktrace+0x3d)[0x558485c94cbd] /usr/libexec/mysqld(handle_fatal_signal+0x515)[0x5584858a94a5] sigaction.c:0(__restore_rt)[0x7f499f4ac5d0] :0(__GI_raise)[0x7f499dbd6207] :0(__GI_abort)[0x7f499dbd78f8] /usr/libexec/mysqld(+0x2d73b7)[0x5584856dc3b7] /usr/libexec/mysqld(+0x6f87d0)[0x558485afd7d0] /usr/libexec/mysqld(+0x657ade)[0x558485a5cade] /usr/libexec/mysqld(+0x671153)[0x558485a76153] /usr/libexec/mysqld(+0x666faf)[0x558485a6bfaf] /usr/libexec/mysqld(+0x668d94)[0x558485a6dd94] /usr/libexec/mysqld(+0x66a6c7)[0x558485a6f6c7] /usr/libexec/mysqld(+0x60a5a0)[0x558485a0f5a0] /usr/libexec/mysqld(+0x60b54b)[0x558485a1054b] /usr/libexec/mysqld(_Z19ha_commit_one_phaseP3THDb+0x80)[0x5584858abac0] /usr/libexec/mysqld(_Z15ha_commit_transP3THDb+0x356)[0x5584858ac236] /usr/libexec/mysqld(_Z17trans_commit_stmtP3THD+0x1b)[0x55848583f3bb] /usr/libexec/mysqld(_Z21mysql_execute_commandP3THD+0x3dc)[0x5584857779ec] /usr/libexec/mysqld(_Z11mysql_parseP3THDPcjP12Parser_state+0x125)[0x55848577e445] /usr/libexec/mysqld(_Z16dispatch_command19enum_server_commandP3THDPcj+0x1750)[0x5584857804a0] /usr/libexec/mysqld(_Z24do_handle_one_connectionP3THD+0x1c2)[0x558485832a22] /usr/libexec/mysqld(handle_one_connection+0x4a)[0x558485832aca] pthread_create.c:0(start_thread)[0x7f499f4a4dd5] /lib64/libc.so.6(clone+0x6d)[0x7f499dc9dead] Trying to get some variables. Some pointers may be invalid and cause the dump to abort. Query (0x7f4958004c18): UPDATE `ipaddresses` SET `lastSeen`='2019-04-24 12:00:01' WHERE `id`='5956' Connection ID (thread ID): 12 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=on,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=off,table_elimination=on,extended_keys=off 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. 190424 12:00:14 mysqld_safe Number of processes running now: 0 190424 12:00:14 mysqld_safe mysqld restarted 190424 12:00:14 [Note] /usr/libexec/mysqld (mysqld 5.5.60-MariaDB) starting as process 6206 ... 190424 12:00:14 InnoDB: The InnoDB memory heap is disabled 190424 12:00:14 InnoDB: Mutexes and rw_locks use GCC atomic builtins 190424 12:00:14 InnoDB: Compressed tables use zlib 1.2.7 190424 12:00:14 InnoDB: Using Linux native AIO 190424 12:00:14 InnoDB: Initializing buffer pool, size = 128.0M 190424 12:00:14 InnoDB: Completed initialization of buffer pool 190424 12:00:14 InnoDB: highest supported file format is Barracuda. 190424 12:00:14 InnoDB: Starting crash recovery from checkpoint LSN=19712482 InnoDB: Restoring possible half-written data pages from the doublewrite buffer... 190424 12:00:14 InnoDB: Starting final batch to recover 3 pages from redo log 190424 12:00:15 InnoDB: Waiting for the background threads to start 190424 12:00:16 Percona XtraDB (http://www.percona.com) 5.5.59-MariaDB-38.11 started; log sequence number 19744500 190424 12:00:16 [Note] Plugin 'FEEDBACK' is disabled. 190424 12:00:16 [Note] Server socket created on IP: '0.0.0.0'. 190424 12:00:16 [Note] Event Scheduler: Loaded 0 events 190424 12:00:16 [Note] /usr/libexec/mysqld: ready for connections. Version: '5.5.60-MariaDB' socket: '/data/mysql/mysql.sock' port: 3306 MariaDB Server 190424 12:15:14 InnoDB: Assertion failure in thread 140493415655168 in file fut0lst.ic line 83 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: http://dev.mysql.com/doc/refman/5.5/en/forcing-innodb-recovery.html InnoDB: about forcing recovery. 190424 12:15:14 [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 http://kb.askmonty.org/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: 5.5.60-MariaDB key_buffer_size=134217728 read_buffer_size=131072 max_used_connections=3 max_threads=153 thread_count=1 It is possible that mysqld could use up to key_buffer_size + (read_buffer_size + sort_buffer_size)*max_threads = 466718 K bytes of memory Hope that's ok; if not, decrease some variables in the equation. Thread pointer: 0x55d241811570 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 = 0x7fc72c221d80 thread_stack 0x48000 /usr/libexec/mysqld(my_print_stacktrace+0x3d)[0x55d23f06fcbd] /usr/libexec/mysqld(handle_fatal_signal+0x515)[0x55d23ec844a5] sigaction.c:0(__restore_rt)[0x7fc72ff155d0] :0(__GI_raise)[0x7fc72e63f207] :0(__GI_abort)[0x7fc72e6408f8] /usr/libexec/mysqld(+0x2d73b7)[0x55d23eab73b7] /usr/libexec/mysqld(+0x6f87d0)[0x55d23eed87d0] /usr/libexec/mysqld(+0x657ade)[0x55d23ee37ade] /usr/libexec/mysqld(+0x671153)[0x55d23ee51153] /usr/libexec/mysqld(+0x666faf)[0x55d23ee46faf] /usr/libexec/mysqld(+0x668d94)[0x55d23ee48d94] /usr/libexec/mysqld(+0x66a6c7)[0x55d23ee4a6c7] /usr/libexec/mysqld(+0x60a5a0)[0x55d23edea5a0] /usr/libexec/mysqld(+0x60b54b)[0x55d23edeb54b] /usr/libexec/mysqld(_Z19ha_commit_one_phaseP3THDb+0x80)[0x55d23ec86ac0] /usr/libexec/mysqld(_Z15ha_commit_transP3THDb+0x356)[0x55d23ec87236] /usr/libexec/mysqld(_Z17trans_commit_stmtP3THD+0x1b)[0x55d23ec1a3bb] /usr/libexec/mysqld(_Z21mysql_execute_commandP3THD+0x3dc)[0x55d23eb529ec] /usr/libexec/mysqld(_Z11mysql_parseP3THDPcjP12Parser_state+0x125)[0x55d23eb59445] /usr/libexec/mysqld(_Z16dispatch_command19enum_server_commandP3THDPcj+0x1750)[0x55d23eb5b4a0] /usr/libexec/mysqld(_Z24do_handle_one_connectionP3THD+0x1c2)[0x55d23ec0da22] /usr/libexec/mysqld(handle_one_connection+0x4a)[0x55d23ec0daca] pthread_create.c:0(start_thread)[0x7fc72ff0ddd5] /lib64/libc.so.6(clone+0x6d)[0x7fc72e706ead] Trying to get some variables. Some pointers may be invalid and cause the dump to abort. Query (0x7fc6e8004c18): UPDATE `ipaddresses` SET `lastSeen`='2019-04-24 12:15:01' WHERE `id`='5956' Connection ID (thread ID): 12 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=on,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=off,table_elimination=on,extended_keys=off 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. 190424 12:15:14 mysqld_safe Number of processes running now: 0 190424 12:15:14 mysqld_safe mysqld restarted 190424 12:15:14 [Note] /usr/libexec/mysqld (mysqld 5.5.60-MariaDB) starting as process 7804 ... 190424 12:15:14 InnoDB: The InnoDB memory heap is disabled 190424 12:15:14 InnoDB: Mutexes and rw_locks use GCC atomic builtins 190424 12:15:14 InnoDB: Compressed tables use zlib 1.2.7 190424 12:15:14 InnoDB: Using Linux native AIO 190424 12:15:14 InnoDB: Initializing buffer pool, size = 128.0M 190424 12:15:14 InnoDB: Completed initialization of buffer pool 190424 12:15:14 InnoDB: highest supported file format is Barracuda. 190424 12:15:14 InnoDB: Starting crash recovery from checkpoint LSN=19750843 InnoDB: Restoring possible half-written data pages from the doublewrite buffer... 190424 12:15:14 InnoDB: Starting final batch to recover 3 pages from redo log 190424 12:15:15 InnoDB: Waiting for the background threads to start 190424 12:15:16 Percona XtraDB (http://www.percona.com) 5.5.59-MariaDB-38.11 started; log sequence number 19783811 190424 12:15:16 [Note] Plugin 'FEEDBACK' is disabled. 190424 12:15:16 [Note] Server socket created on IP: '0.0.0.0'. 190424 12:15:16 [Note] Event Scheduler: Loaded 0 events 190424 12:15:16 [Note] /usr/libexec/mysqld: ready for connections. Version: '5.5.60-MariaDB' socket: '/data/mysql/mysql.sock' port: 3306 MariaDB Server 190424 12:30:14 InnoDB: Assertion failure in thread 139890995263232 in file fut0lst.ic line 83 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: http://dev.mysql.com/doc/refman/5.5/en/forcing-innodb-recovery.html InnoDB: about forcing recovery. 190424 12:30:14 [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 http://kb.askmonty.org/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: 5.5.60-MariaDB key_buffer_size=134217728 read_buffer_size=131072 max_used_connections=3 max_threads=153 thread_count=1 It is possible that mysqld could use up to key_buffer_size + (read_buffer_size + sort_buffer_size)*max_threads = 466718 K bytes of memory Hope that's ok; if not, decrease some variables in the equation. Thread pointer: 0x558e593fb730 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 = 0x7f3ae9146d80 thread_stack 0x48000 /usr/libexec/mysqld(my_print_stacktrace+0x3d)[0x558e565f5cbd] /usr/libexec/mysqld(handle_fatal_signal+0x515)[0x558e5620a4a5] sigaction.c:0(__restore_rt)[0x7f3b064025d0] :0(__GI_raise)[0x7f3b04b2c207] :0(__GI_abort)[0x7f3b04b2d8f8] /usr/libexec/mysqld(+0x2d73b7)[0x558e5603d3b7] /usr/libexec/mysqld(+0x6f87d0)[0x558e5645e7d0] /usr/libexec/mysqld(+0x657ade)[0x558e563bdade] /usr/libexec/mysqld(+0x671153)[0x558e563d7153] /usr/libexec/mysqld(+0x666faf)[0x558e563ccfaf] /usr/libexec/mysqld(+0x668d94)[0x558e563ced94] /usr/libexec/mysqld(+0x66a6c7)[0x558e563d06c7] /usr/libexec/mysqld(+0x60a5a0)[0x558e563705a0] /usr/libexec/mysqld(+0x60b54b)[0x558e5637154b] /usr/libexec/mysqld(_Z19ha_commit_one_phaseP3THDb+0x80)[0x558e5620cac0] /usr/libexec/mysqld(_Z15ha_commit_transP3THDb+0x356)[0x558e5620d236] /usr/libexec/mysqld(_Z17trans_commit_stmtP3THD+0x1b)[0x558e561a03bb] /usr/libexec/mysqld(_Z21mysql_execute_commandP3THD+0x3dc)[0x558e560d89ec] /usr/libexec/mysqld(_Z11mysql_parseP3THDPcjP12Parser_state+0x125)[0x558e560df445] /usr/libexec/mysqld(_Z16dispatch_command19enum_server_commandP3THDPcj+0x1750)[0x558e560e14a0] /usr/libexec/mysqld(_Z24do_handle_one_connectionP3THD+0x1c2)[0x558e56193a22] /usr/libexec/mysqld(handle_one_connection+0x4a)[0x558e56193aca] pthread_create.c:0(start_thread)[0x7f3b063fadd5] /lib64/libc.so.6(clone+0x6d)[0x7f3b04bf3ead] Trying to get some variables. Some pointers may be invalid and cause the dump to abort. Query (0x7f3ac0004c18): UPDATE `ipaddresses` SET `lastSeen`='2019-04-24 12:30:01' WHERE `id`='5956' Connection ID (thread ID): 12 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=on,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=off,table_elimination=on,extended_keys=off 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. 190424 12:30:14 mysqld_safe Number of processes running now: 0 190424 12:30:14 mysqld_safe mysqld restarted 190424 12:30:14 [Note] /usr/libexec/mysqld (mysqld 5.5.60-MariaDB) starting as process 9844 ... 190424 12:30:14 InnoDB: The InnoDB memory heap is disabled 190424 12:30:14 InnoDB: Mutexes and rw_locks use GCC atomic builtins 190424 12:30:14 InnoDB: Compressed tables use zlib 1.2.7 190424 12:30:14 InnoDB: Using Linux native AIO 190424 12:30:14 InnoDB: Initializing buffer pool, size = 128.0M 190424 12:30:14 InnoDB: Completed initialization of buffer pool 190424 12:30:14 InnoDB: highest supported file format is Barracuda. 190424 12:30:14 InnoDB: Starting crash recovery from checkpoint LSN=19789929 InnoDB: Restoring possible half-written data pages from the doublewrite buffer... 190424 12:30:14 InnoDB: Starting final batch to recover 3 pages from redo log 190424 12:30:14 InnoDB: Waiting for the background threads to start 190424 12:30:15 Percona XtraDB (http://www.percona.com) 5.5.59-MariaDB-38.11 started; log sequence number 19821949 190424 12:30:16 [Note] Plugin 'FEEDBACK' is disabled. 190424 12:30:16 [Note] Server socket created on IP: '0.0.0.0'. 190424 12:30:16 [Note] Event Scheduler: Loaded 0 events 190424 12:30:16 [Note] /usr/libexec/mysqld: ready for connections. Version: '5.5.60-MariaDB' socket: '/data/mysql/mysql.sock' port: 3306 MariaDB Server 190424 12:45:13 InnoDB: Assertion failure in thread 140524459124480 in file fut0lst.ic line 83 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: http://dev.mysql.com/doc/refman/5.5/en/forcing-innodb-recovery.html InnoDB: about forcing recovery. 190424 12:45:13 [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 http://kb.askmonty.org/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: 5.5.60-MariaDB key_buffer_size=134217728 read_buffer_size=131072 max_used_connections=3 max_threads=153 thread_count=1 It is possible that mysqld could use up to key_buffer_size + (read_buffer_size + sort_buffer_size)*max_threads = 466718 K bytes of memory Hope that's ok; if not, decrease some variables in the equation. Thread pointer: 0x559c1d1003b0 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 = 0x7fce6677dd80 thread_stack 0x48000 /usr/libexec/mysqld(my_print_stacktrace+0x3d)[0x559c1ad40cbd] /usr/libexec/mysqld(handle_fatal_signal+0x515)[0x559c1a9554a5] sigaction.c:0(__restore_rt)[0x7fce83a2a5d0] :0(__GI_raise)[0x7fce82154207] :0(__GI_abort)[0x7fce821558f8] /usr/libexec/mysqld(+0x2d73b7)[0x559c1a7883b7] /usr/libexec/mysqld(+0x6f87d0)[0x559c1aba97d0] /usr/libexec/mysqld(+0x657ade)[0x559c1ab08ade] /usr/libexec/mysqld(+0x671153)[0x559c1ab22153] /usr/libexec/mysqld(+0x666faf)[0x559c1ab17faf] /usr/libexec/mysqld(+0x668d94)[0x559c1ab19d94] /usr/libexec/mysqld(+0x66a6c7)[0x559c1ab1b6c7] /usr/libexec/mysqld(+0x60a5a0)[0x559c1aabb5a0] /usr/libexec/mysqld(+0x60b54b)[0x559c1aabc54b] /usr/libexec/mysqld(_Z19ha_commit_one_phaseP3THDb+0x80)[0x559c1a957ac0] /usr/libexec/mysqld(_Z15ha_commit_transP3THDb+0x356)[0x559c1a958236] /usr/libexec/mysqld(_Z17trans_commit_stmtP3THD+0x1b)[0x559c1a8eb3bb] /usr/libexec/mysqld(_Z21mysql_execute_commandP3THD+0x3dc)[0x559c1a8239ec] /usr/libexec/mysqld(_Z11mysql_parseP3THDPcjP12Parser_state+0x125)[0x559c1a82a445] /usr/libexec/mysqld(_Z16dispatch_command19enum_server_commandP3THDPcj+0x1750)[0x559c1a82c4a0] /usr/libexec/mysqld(_Z24do_handle_one_connectionP3THD+0x1c2)[0x559c1a8dea22] /usr/libexec/mysqld(handle_one_connection+0x4a)[0x559c1a8deaca] pthread_create.c:0(start_thread)[0x7fce83a22dd5] /lib64/libc.so.6(clone+0x6d)[0x7fce8221bead] Trying to get some variables. Some pointers may be invalid and cause the dump to abort. Query (0x7fce3c004c18): UPDATE `ipaddresses` SET `lastSeen`='2019-04-24 12:45:01' WHERE `id`='5956' Connection ID (thread ID): 12 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=on,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=off,table_elimination=on,extended_keys=off 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. 190424 12:45:13 mysqld_safe Number of processes running now: 0 190424 12:45:13 mysqld_safe mysqld restarted 190424 12:45:13 [Note] /usr/libexec/mysqld (mysqld 5.5.60-MariaDB) starting as process 11415 ... 190424 12:45:14 InnoDB: The InnoDB memory heap is disabled 190424 12:45:14 InnoDB: Mutexes and rw_locks use GCC atomic builtins 190424 12:45:14 InnoDB: Compressed tables use zlib 1.2.7 190424 12:45:14 InnoDB: Using Linux native AIO 190424 12:45:14 InnoDB: Initializing buffer pool, size = 128.0M 190424 12:45:14 InnoDB: Completed initialization of buffer pool 190424 12:45:14 InnoDB: highest supported file format is Barracuda. 190424 12:45:14 InnoDB: Starting crash recovery from checkpoint LSN=19828522 InnoDB: Restoring possible half-written data pages from the doublewrite buffer... 190424 12:45:14 InnoDB: Starting final batch to recover 3 pages from redo log 190424 12:45:14 InnoDB: Waiting for the background threads to start 190424 12:45:15 Percona XtraDB (http://www.percona.com) 5.5.59-MariaDB-38.11 started; log sequence number 19862912 190424 12:45:15 [Note] Plugin 'FEEDBACK' is disabled. 190424 12:45:15 [Note] Server socket created on IP: '0.0.0.0'. 190424 12:45:15 [Note] Event Scheduler: Loaded 0 events 190424 12:45:15 [Note] /usr/libexec/mysqld: ready for connections. Version: '5.5.60-MariaDB' socket: '/data/mysql/mysql.sock' port: 3306 MariaDB Server 190424 13:00:13 InnoDB: Assertion failure in thread 139665561147136 in file fut0lst.ic line 83 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: http://dev.mysql.com/doc/refman/5.5/en/forcing-innodb-recovery.html InnoDB: about forcing recovery. 190424 13:00:13 [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 http://kb.askmonty.org/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: 5.5.60-MariaDB key_buffer_size=134217728 read_buffer_size=131072 max_used_connections=3 max_threads=153 thread_count=1 It is possible that mysqld could use up to key_buffer_size + (read_buffer_size + sort_buffer_size)*max_threads = 466718 K bytes of memory Hope that's ok; if not, decrease some variables in the equation. Thread pointer: 0x55f16da46f90 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 = 0x7f066c28cd80 thread_stack 0x48000 /usr/libexec/mysqld(my_print_stacktrace+0x3d)[0x55f16b9f2cbd] /usr/libexec/mysqld(handle_fatal_signal+0x515)[0x55f16b6074a5] sigaction.c:0(__restore_rt)[0x7f06718a15d0] :0(__GI_raise)[0x7f066ffcb207] :0(__GI_abort)[0x7f066ffcc8f8] /usr/libexec/mysqld(+0x2d73b7)[0x55f16b43a3b7] /usr/libexec/mysqld(+0x6f87d0)[0x55f16b85b7d0] /usr/libexec/mysqld(+0x657ade)[0x55f16b7baade] /usr/libexec/mysqld(+0x671153)[0x55f16b7d4153] /usr/libexec/mysqld(+0x666faf)[0x55f16b7c9faf] /usr/libexec/mysqld(+0x668d94)[0x55f16b7cbd94] /usr/libexec/mysqld(+0x66a6c7)[0x55f16b7cd6c7] /usr/libexec/mysqld(+0x60a5a0)[0x55f16b76d5a0] /usr/libexec/mysqld(+0x60b54b)[0x55f16b76e54b] /usr/libexec/mysqld(_Z19ha_commit_one_phaseP3THDb+0x80)[0x55f16b609ac0] /usr/libexec/mysqld(_Z15ha_commit_transP3THDb+0x356)[0x55f16b60a236] /usr/libexec/mysqld(_Z17trans_commit_stmtP3THD+0x1b)[0x55f16b59d3bb] /usr/libexec/mysqld(_Z21mysql_execute_commandP3THD+0x3dc)[0x55f16b4d59ec] /usr/libexec/mysqld(_Z11mysql_parseP3THDPcjP12Parser_state+0x125)[0x55f16b4dc445] /usr/libexec/mysqld(_Z16dispatch_command19enum_server_commandP3THDPcj+0x1750)[0x55f16b4de4a0] /usr/libexec/mysqld(_Z24do_handle_one_connectionP3THD+0x1c2)[0x55f16b590a22] /usr/libexec/mysqld(handle_one_connection+0x4a)[0x55f16b590aca] pthread_create.c:0(start_thread)[0x7f0671899dd5] /lib64/libc.so.6(clone+0x6d)[0x7f0670092ead] Trying to get some variables. Some pointers may be invalid and cause the dump to abort. Query (0x7f062c004c18): UPDATE `ipaddresses` SET `lastSeen`='2019-04-24 13:00:02' WHERE `id`='5956' Connection ID (thread ID): 12 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=on,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=off,table_elimination=on,extended_keys=off 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. 190424 13:00:14 mysqld_safe Number of processes running now: 0 190424 13:00:14 mysqld_safe mysqld restarted 190424 13:00:14 [Note] /usr/libexec/mysqld (mysqld 5.5.60-MariaDB) starting as process 13464 ... 190424 13:00:14 InnoDB: The InnoDB memory heap is disabled 190424 13:00:14 InnoDB: Mutexes and rw_locks use GCC atomic builtins 190424 13:00:14 InnoDB: Compressed tables use zlib 1.2.7 190424 13:00:14 InnoDB: Using Linux native AIO 190424 13:00:14 InnoDB: Initializing buffer pool, size = 128.0M 190424 13:00:14 InnoDB: Completed initialization of buffer pool 190424 13:00:14 InnoDB: highest supported file format is Barracuda. 190424 13:00:14 InnoDB: Starting crash recovery from checkpoint LSN=19869475 InnoDB: Restoring possible half-written data pages from the doublewrite buffer... 190424 13:00:14 InnoDB: Starting final batch to recover 5 pages from redo log 190424 13:00:14 InnoDB: Waiting for the background threads to start 190424 13:00:15 Percona XtraDB (http://www.percona.com) 5.5.59-MariaDB-38.11 started; log sequence number 19904718 190424 13:00:15 [Note] Plugin 'FEEDBACK' is disabled. 190424 13:00:15 [Note] Server socket created on IP: '0.0.0.0'. 190424 13:00:15 [Note] Event Scheduler: Loaded 0 events 190424 13:00:15 [Note] /usr/libexec/mysqld: ready for connections. Version: '5.5.60-MariaDB' socket: '/data/mysql/mysql.sock' port: 3306 MariaDB Server 190424 13:15:13 InnoDB: Assertion failure in thread 140636491052800 in file fut0lst.ic line 83 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: http://dev.mysql.com/doc/refman/5.5/en/forcing-innodb-recovery.html InnoDB: about forcing recovery. 190424 13:15:13 [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 http://kb.askmonty.org/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: 5.5.60-MariaDB key_buffer_size=134217728 read_buffer_size=131072 max_used_connections=3 max_threads=153 thread_count=1 It is possible that mysqld could use up to key_buffer_size + (read_buffer_size + sort_buffer_size)*max_threads = 466718 K bytes of memory Hope that's ok; if not, decrease some variables in the equation. Thread pointer: 0x55d2bfbee030 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 = 0x7fe87c176d80 thread_stack 0x48000 /usr/libexec/mysqld(my_print_stacktrace+0x3d)[0x55d2bc597cbd] /usr/libexec/mysqld(handle_fatal_signal+0x515)[0x55d2bc1ac4a5] sigaction.c:0(__restore_rt)[0x7fe881fd65d0] :0(__GI_raise)[0x7fe880700207] :0(__GI_abort)[0x7fe8807018f8] /usr/libexec/mysqld(+0x2d73b7)[0x55d2bbfdf3b7] /usr/libexec/mysqld(+0x6f87d0)[0x55d2bc4007d0] /usr/libexec/mysqld(+0x657ade)[0x55d2bc35fade] /usr/libexec/mysqld(+0x671153)[0x55d2bc379153] /usr/libexec/mysqld(+0x666faf)[0x55d2bc36efaf] /usr/libexec/mysqld(+0x668d94)[0x55d2bc370d94] /usr/libexec/mysqld(+0x66a6c7)[0x55d2bc3726c7] /usr/libexec/mysqld(+0x60a5a0)[0x55d2bc3125a0] /usr/libexec/mysqld(+0x60b54b)[0x55d2bc31354b] /usr/libexec/mysqld(_Z19ha_commit_one_phaseP3THDb+0x80)[0x55d2bc1aeac0] /usr/libexec/mysqld(_Z15ha_commit_transP3THDb+0x356)[0x55d2bc1af236] /usr/libexec/mysqld(_Z17trans_commit_stmtP3THD+0x1b)[0x55d2bc1423bb] /usr/libexec/mysqld(_Z21mysql_execute_commandP3THD+0x3dc)[0x55d2bc07a9ec] /usr/libexec/mysqld(_Z11mysql_parseP3THDPcjP12Parser_state+0x125)[0x55d2bc081445] /usr/libexec/mysqld(_Z16dispatch_command19enum_server_commandP3THDPcj+0x1750)[0x55d2bc0834a0] /usr/libexec/mysqld(_Z24do_handle_one_connectionP3THD+0x1c2)[0x55d2bc135a22] /usr/libexec/mysqld(handle_one_connection+0x4a)[0x55d2bc135aca] pthread_create.c:0(start_thread)[0x7fe881fcedd5] /lib64/libc.so.6(clone+0x6d)[0x7fe8807c7ead] Trying to get some variables. Some pointers may be invalid and cause the dump to abort. Query (0x7fe8380116e8): UPDATE `ipaddresses` SET `lastSeen`='2019-04-24 13:15:01' WHERE `id`='5956' Connection ID (thread ID): 12 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=on,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=off,table_elimination=on,extended_keys=off 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. 190424 13:15:13 mysqld_safe Number of processes running now: 0 190424 13:15:13 mysqld_safe mysqld restarted 190424 13:15:13 [Note] /usr/libexec/mysqld (mysqld 5.5.60-MariaDB) starting as process 15053 ... 190424 13:15:13 InnoDB: The InnoDB memory heap is disabled 190424 13:15:13 InnoDB: Mutexes and rw_locks use GCC atomic builtins 190424 13:15:13 InnoDB: Compressed tables use zlib 1.2.7 190424 13:15:13 InnoDB: Using Linux native AIO 190424 13:15:13 InnoDB: Initializing buffer pool, size = 128.0M 190424 13:15:13 InnoDB: Completed initialization of buffer pool 190424 13:15:13 InnoDB: highest supported file format is Barracuda. 190424 13:15:13 InnoDB: Starting crash recovery from checkpoint LSN=19911294 InnoDB: Restoring possible half-written data pages from the doublewrite buffer... 190424 13:15:13 InnoDB: Starting final batch to recover 3 pages from redo log 190424 13:15:14 InnoDB: Waiting for the background threads to start 190424 13:15:15 Percona XtraDB (http://www.percona.com) 5.5.59-MariaDB-38.11 started; log sequence number 19946278 190424 13:15:15 [Note] Plugin 'FEEDBACK' is disabled. 190424 13:15:15 [Note] Server socket created on IP: '0.0.0.0'. 190424 13:15:15 [Note] Event Scheduler: Loaded 0 events 190424 13:15:15 [Note] /usr/libexec/mysqld: ready for connections. Version: '5.5.60-MariaDB' socket: '/data/mysql/mysql.sock' port: 3306 MariaDB Server 190424 13:21:31 InnoDB: Assertion failure in thread 140194983241472 in file fut0lst.ic line 83 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: http://dev.mysql.com/doc/refman/5.5/en/forcing-innodb-recovery.html InnoDB: about forcing recovery. 190424 13:21:31 [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 http://kb.askmonty.org/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: 5.5.60-MariaDB key_buffer_size=134217728 read_buffer_size=131072 max_used_connections=7 max_threads=153 thread_count=1 It is possible that mysqld could use up to key_buffer_size + (read_buffer_size + sort_buffer_size)*max_threads = 466718 K bytes of memory Hope that's ok; if not, decrease some variables in the equation. Thread pointer: 0x55fa5d42ebd0 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 = 0x7f81b02cdd80 thread_stack 0x48000 /usr/libexec/mysqld(my_print_stacktrace+0x3d)[0x55fa59d91cbd] /usr/libexec/mysqld(handle_fatal_signal+0x515)[0x55fa599a64a5] sigaction.c:0(__restore_rt)[0x7f81b41d45d0] :0(__GI_raise)[0x7f81b28fe207] :0(__GI_abort)[0x7f81b28ff8f8] /usr/libexec/mysqld(+0x2d73b7)[0x55fa597d93b7] /usr/libexec/mysqld(+0x6f87d0)[0x55fa59bfa7d0] /usr/libexec/mysqld(+0x657ade)[0x55fa59b59ade] /usr/libexec/mysqld(+0x671153)[0x55fa59b73153] /usr/libexec/mysqld(+0x666faf)[0x55fa59b68faf] /usr/libexec/mysqld(+0x668d94)[0x55fa59b6ad94] /usr/libexec/mysqld(+0x66a6c7)[0x55fa59b6c6c7] /usr/libexec/mysqld(+0x60a5a0)[0x55fa59b0c5a0] /usr/libexec/mysqld(+0x60b54b)[0x55fa59b0d54b] /usr/libexec/mysqld(_Z19ha_commit_one_phaseP3THDb+0x80)[0x55fa599a8ac0] /usr/libexec/mysqld(_Z15ha_commit_transP3THDb+0x356)[0x55fa599a9236] /usr/libexec/mysqld(_Z17trans_commit_stmtP3THD+0x1b)[0x55fa5993c3bb] /usr/libexec/mysqld(_Z21mysql_execute_commandP3THD+0x3dc)[0x55fa598749ec] /usr/libexec/mysqld(_Z11mysql_parseP3THDPcjP12Parser_state+0x125)[0x55fa5987b445] /usr/libexec/mysqld(_Z16dispatch_command19enum_server_commandP3THDPcj+0x1750)[0x55fa5987d4a0] /usr/libexec/mysqld(_Z24do_handle_one_connectionP3THD+0x1c2)[0x55fa5992fa22] /usr/libexec/mysqld(handle_one_connection+0x4a)[0x55fa5992faca] pthread_create.c:0(start_thread)[0x7f81b41ccdd5] /lib64/libc.so.6(clone+0x6d)[0x7f81b29c5ead] Trying to get some variables. Some pointers may be invalid and cause the dump to abort. Query (0x7f816c004c18): UPDATE `subnets` SET `isFolder`='0',`masterSubnetId`='0',`subnet`='183740960',`mask`='28',`description`='MeyerW_SAP_HANA_Repl3 VLAN:1264',`vlanId`='170',`allowRequests`='0',`showName`='0',`discoverSubnet`='0',`pingSubnet`='0',`resolveDNS`='0',`scanAgent`='0',`DNSrecursive`='0',`DNSrecords`='0',`nameserverId`='0',`device`='0',`isFull`='0',`location`='0',`threshold`='0',`sectionId`='11',`custom_Gateway`='None',`custom_Routing_information`=NULL WHERE `id`='567' Connection ID (thread ID): 226 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=on,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=off,table_elimination=on,extended_keys=off 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. 190424 13:21:32 mysqld_safe Number of processes running now: 0 190424 13:21:32 mysqld_safe mysqld restarted 190424 13:21:32 [Note] /usr/libexec/mysqld (mysqld 5.5.60-MariaDB) starting as process 16093 ... 190424 13:21:32 InnoDB: The InnoDB memory heap is disabled 190424 13:21:32 InnoDB: Mutexes and rw_locks use GCC atomic builtins 190424 13:21:32 InnoDB: Compressed tables use zlib 1.2.7 190424 13:21:32 InnoDB: Using Linux native AIO 190424 13:21:32 InnoDB: Initializing buffer pool, size = 128.0M 190424 13:21:32 InnoDB: Completed initialization of buffer pool 190424 13:21:32 InnoDB: highest supported file format is Barracuda. 190424 13:21:32 InnoDB: Starting crash recovery from checkpoint LSN=19974859 InnoDB: Restoring possible half-written data pages from the doublewrite buffer... 190424 13:21:32 InnoDB: Starting final batch to recover 1 pages from redo log 190424 13:21:32 InnoDB: Waiting for the background threads to start 190424 13:21:33 Percona XtraDB (http://www.percona.com) 5.5.59-MariaDB-38.11 started; log sequence number 19975133 190424 13:21:33 [Note] Plugin 'FEEDBACK' is disabled. 190424 13:21:33 [Note] Server socket created on IP: '0.0.0.0'. 190424 13:21:33 [Note] Event Scheduler: Loaded 0 events 190424 13:21:33 [Note] /usr/libexec/mysqld: ready for connections. Version: '5.5.60-MariaDB' socket: '/data/mysql/mysql.sock' port: 3306 MariaDB Server 190424 13:30:13 InnoDB: Assertion failure in thread 140397248583424 in file fut0lst.ic line 83 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: http://dev.mysql.com/doc/refman/5.5/en/forcing-innodb-recovery.html InnoDB: about forcing recovery. 190424 13:30:13 [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 http://kb.askmonty.org/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: 5.5.60-MariaDB key_buffer_size=134217728 read_buffer_size=131072 max_used_connections=3 max_threads=153 thread_count=1 It is possible that mysqld could use up to key_buffer_size + (read_buffer_size + sort_buffer_size)*max_threads = 466718 K bytes of memory Hope that's ok; if not, decrease some variables in the equation. Thread pointer: 0x5573160ab5c0 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 = 0x7fb0c8210d80 thread_stack 0x48000 /usr/libexec/mysqld(my_print_stacktrace+0x3d)[0x5573127b9cbd] /usr/libexec/mysqld(handle_fatal_signal+0x515)[0x5573123ce4a5] sigaction.c:0(__restore_rt)[0x7fb0cc9185d0] :0(__GI_raise)[0x7fb0cb042207] :0(__GI_abort)[0x7fb0cb0438f8] /usr/libexec/mysqld(+0x2d73b7)[0x5573122013b7] /usr/libexec/mysqld(+0x6f87d0)[0x5573126227d0] /usr/libexec/mysqld(+0x657ade)[0x557312581ade] /usr/libexec/mysqld(+0x671153)[0x55731259b153] /usr/libexec/mysqld(+0x666faf)[0x557312590faf] /usr/libexec/mysqld(+0x668d94)[0x557312592d94] /usr/libexec/mysqld(+0x66a6c7)[0x5573125946c7] /usr/libexec/mysqld(+0x60a5a0)[0x5573125345a0] /usr/libexec/mysqld(+0x60b54b)[0x55731253554b] /usr/libexec/mysqld(_Z19ha_commit_one_phaseP3THDb+0x80)[0x5573123d0ac0] /usr/libexec/mysqld(_Z15ha_commit_transP3THDb+0x356)[0x5573123d1236] /usr/libexec/mysqld(_Z17trans_commit_stmtP3THD+0x1b)[0x5573123643bb] /usr/libexec/mysqld(_Z21mysql_execute_commandP3THD+0x3dc)[0x55731229c9ec] /usr/libexec/mysqld(_Z11mysql_parseP3THDPcjP12Parser_state+0x125)[0x5573122a3445] /usr/libexec/mysqld(_Z16dispatch_command19enum_server_commandP3THDPcj+0x1750)[0x5573122a54a0] /usr/libexec/mysqld(_Z24do_handle_one_connectionP3THD+0x1c2)[0x557312357a22] /usr/libexec/mysqld(handle_one_connection+0x4a)[0x557312357aca] pthread_create.c:0(start_thread)[0x7fb0cc910dd5] /lib64/libc.so.6(clone+0x6d)[0x7fb0cb109ead] Trying to get some variables. Some pointers may be invalid and cause the dump to abort. Query (0x7fb08c006808): UPDATE `ipaddresses` SET `lastSeen`='2019-04-24 13:30:01' WHERE `id`='5979' Connection ID (thread ID): 30 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=on,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=off,table_elimination=on,extended_keys=off 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. 190424 13:30:14 mysqld_safe Number of processes running now: 0 190424 13:30:14 mysqld_safe mysqld restarted 190424 13:30:14 [Note] /usr/libexec/mysqld (mysqld 5.5.60-MariaDB) starting as process 17710 ... 190424 13:30:14 InnoDB: The InnoDB memory heap is disabled 190424 13:30:14 InnoDB: Mutexes and rw_locks use GCC atomic builtins 190424 13:30:14 InnoDB: Compressed tables use zlib 1.2.7 190424 13:30:14 InnoDB: Using Linux native AIO 190424 13:30:14 InnoDB: Initializing buffer pool, size = 128.0M 190424 13:30:14 InnoDB: Completed initialization of buffer pool 190424 13:30:14 InnoDB: highest supported file format is Barracuda. 190424 13:30:14 InnoDB: Starting crash recovery from checkpoint LSN=19985187 InnoDB: Restoring possible half-written data pages from the doublewrite buffer... 190424 13:30:14 InnoDB: Starting final batch to recover 3 pages from redo log 190424 13:30:14 InnoDB: Waiting for the background threads to start 190424 13:30:15 Percona XtraDB (http://www.percona.com) 5.5.59-MariaDB-38.11 started; log sequence number 19988097 190424 13:30:15 [Note] Plugin 'FEEDBACK' is disabled. 190424 13:30:15 [Note] Server socket created on IP: '0.0.0.0'. 190424 13:30:15 [Note] Event Scheduler: Loaded 0 events 190424 13:30:15 [Note] /usr/libexec/mysqld: ready for connections. Version: '5.5.60-MariaDB' socket: '/data/mysql/mysql.sock' port: 3306 MariaDB Server 190424 13:45:13 InnoDB: Assertion failure in thread 140094655928064 in file fut0lst.ic line 83 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: http://dev.mysql.com/doc/refman/5.5/en/forcing-innodb-recovery.html InnoDB: about forcing recovery. 190424 13:45:13 [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 http://kb.askmonty.org/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: 5.5.60-MariaDB key_buffer_size=134217728 read_buffer_size=131072 max_used_connections=5 max_threads=153 thread_count=1 It is possible that mysqld could use up to key_buffer_size + (read_buffer_size + sort_buffer_size)*max_threads = 466718 K bytes of memory Hope that's ok; if not, decrease some variables in the equation. Thread pointer: 0x561304fae460 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 = 0x7f6a54338d80 thread_stack 0x48000 /usr/libexec/mysqld(my_print_stacktrace+0x3d)[0x561302529cbd] /usr/libexec/mysqld(handle_fatal_signal+0x515)[0x56130213e4a5] sigaction.c:0(__restore_rt)[0x7f6a597ce5d0] :0(__GI_raise)[0x7f6a57ef8207] :0(__GI_abort)[0x7f6a57ef98f8] /usr/libexec/mysqld(+0x2d73b7)[0x561301f713b7] /usr/libexec/mysqld(+0x6f87d0)[0x5613023927d0] /usr/libexec/mysqld(+0x657ade)[0x5613022f1ade] /usr/libexec/mysqld(+0x671153)[0x56130230b153] /usr/libexec/mysqld(+0x666faf)[0x561302300faf] /usr/libexec/mysqld(+0x668d94)[0x561302302d94] /usr/libexec/mysqld(+0x66a6c7)[0x5613023046c7] /usr/libexec/mysqld(+0x60a5a0)[0x5613022a45a0] /usr/libexec/mysqld(+0x60b54b)[0x5613022a554b] /usr/libexec/mysqld(_Z19ha_commit_one_phaseP3THDb+0x80)[0x561302140ac0] /usr/libexec/mysqld(_Z15ha_commit_transP3THDb+0x356)[0x561302141236] /usr/libexec/mysqld(_Z17trans_commit_stmtP3THD+0x1b)[0x5613020d43bb] /usr/libexec/mysqld(_Z21mysql_execute_commandP3THD+0x3dc)[0x56130200c9ec] /usr/libexec/mysqld(_Z11mysql_parseP3THDPcjP12Parser_state+0x125)[0x561302013445] /usr/libexec/mysqld(_Z16dispatch_command19enum_server_commandP3THDPcj+0x1750)[0x5613020154a0] /usr/libexec/mysqld(_Z24do_handle_one_connectionP3THD+0x1c2)[0x5613020c7a22] /usr/libexec/mysqld(handle_one_connection+0x4a)[0x5613020c7aca] pthread_create.c:0(start_thread)[0x7f6a597c6dd5] /lib64/libc.so.6(clone+0x6d)[0x7f6a57fbfead] Trying to get some variables. Some pointers may be invalid and cause the dump to abort. Query (0x7f6a14004c18): UPDATE `ipaddresses` SET `lastSeen`='2019-04-24 13:45:01' WHERE `id`='5930' Connection ID (thread ID): 46 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=on,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=off,table_elimination=on,extended_keys=off 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. 190424 13:45:13 mysqld_safe Number of processes running now: 0 190424 13:45:13 mysqld_safe mysqld restarted 190424 13:45:13 [Note] /usr/libexec/mysqld (mysqld 5.5.60-MariaDB) starting as process 19374 ... 190424 13:45:13 InnoDB: The InnoDB memory heap is disabled 190424 13:45:13 InnoDB: Mutexes and rw_locks use GCC atomic builtins 190424 13:45:13 InnoDB: Compressed tables use zlib 1.2.7 190424 13:45:13 InnoDB: Using Linux native AIO 190424 13:45:13 InnoDB: Initializing buffer pool, size = 128.0M 190424 13:45:13 InnoDB: Completed initialization of buffer pool 190424 13:45:13 InnoDB: highest supported file format is Barracuda. 190424 13:45:13 InnoDB: Starting crash recovery from checkpoint LSN=20000365 InnoDB: Restoring possible half-written data pages from the doublewrite buffer... 190424 13:45:13 InnoDB: Starting final batch to recover 5 pages from redo log 190424 13:45:14 InnoDB: Waiting for the background threads to start 190424 13:45:15 Percona XtraDB (http://www.percona.com) 5.5.59-MariaDB-38.11 started; log sequence number 20028498 190424 13:45:15 [Note] Plugin 'FEEDBACK' is disabled. 190424 13:45:15 [Note] Server socket created on IP: '0.0.0.0'. 190424 13:45:15 [Note] Event Scheduler: Loaded 0 events 190424 13:45:15 [Note] /usr/libexec/mysqld: ready for connections. Version: '5.5.60-MariaDB' socket: '/data/mysql/mysql.sock' port: 3306 MariaDB Server 190424 13:47:42 InnoDB: Assertion failure in thread 140379799033600 in file fut0lst.ic line 83 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: http://dev.mysql.com/doc/refman/5.5/en/forcing-innodb-recovery.html InnoDB: about forcing recovery. 190424 13:47:42 [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 http://kb.askmonty.org/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: 5.5.60-MariaDB key_buffer_size=134217728 read_buffer_size=131072 max_used_connections=3 max_threads=153 thread_count=1 It is possible that mysqld could use up to key_buffer_size + (read_buffer_size + sort_buffer_size)*max_threads = 466718 K bytes of memory Hope that's ok; if not, decrease some variables in the equation. Thread pointer: 0x55f0b3709e20 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 = 0x7facb80e0d80 thread_stack 0x48000 /usr/libexec/mysqld(my_print_stacktrace+0x3d)[0x55f0b0d96cbd] /usr/libexec/mysqld(handle_fatal_signal+0x515)[0x55f0b09ab4a5] sigaction.c:0(__restore_rt)[0x7facbd56a5d0] :0(__GI_raise)[0x7facbbc94207] :0(__GI_abort)[0x7facbbc958f8] /usr/libexec/mysqld(+0x2d73b7)[0x55f0b07de3b7] /usr/libexec/mysqld(+0x6f87d0)[0x55f0b0bff7d0] /usr/libexec/mysqld(+0x657ade)[0x55f0b0b5eade] /usr/libexec/mysqld(+0x671153)[0x55f0b0b78153] /usr/libexec/mysqld(+0x666faf)[0x55f0b0b6dfaf] /usr/libexec/mysqld(+0x668d94)[0x55f0b0b6fd94] /usr/libexec/mysqld(+0x66a6c7)[0x55f0b0b716c7] /usr/libexec/mysqld(+0x60a5a0)[0x55f0b0b115a0] /usr/libexec/mysqld(+0x60b54b)[0x55f0b0b1254b] /usr/libexec/mysqld(_Z19ha_commit_one_phaseP3THDb+0x80)[0x55f0b09adac0] /usr/libexec/mysqld(_Z15ha_commit_transP3THDb+0x356)[0x55f0b09ae236] /usr/libexec/mysqld(_Z17trans_commit_stmtP3THD+0x1b)[0x55f0b09413bb] /usr/libexec/mysqld(_Z21mysql_execute_commandP3THD+0x3dc)[0x55f0b08799ec] /usr/libexec/mysqld(_Z11mysql_parseP3THDPcjP12Parser_state+0x125)[0x55f0b0880445] /usr/libexec/mysqld(_Z16dispatch_command19enum_server_commandP3THDPcj+0x1750)[0x55f0b08824a0] /usr/libexec/mysqld(_Z24do_handle_one_connectionP3THD+0x1c2)[0x55f0b0934a22] /usr/libexec/mysqld(handle_one_connection+0x4a)[0x55f0b0934aca] pthread_create.c:0(start_thread)[0x7facbd562dd5] /lib64/libc.so.6(clone+0x6d)[0x7facbbd5bead] Trying to get some variables. Some pointers may be invalid and cause the dump to abort. Query (0x7fac74027298): UPDATE `ipaddresses` SET `lastSeen`='2019-04-24 11:47:42' WHERE `id`='5903' Connection ID (thread ID): 10 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=on,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=off,table_elimination=on,extended_keys=off 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. 190424 13:47:42 mysqld_safe Number of processes running now: 0 190424 13:47:42 mysqld_safe mysqld restarted 190424 13:47:42 [Note] /usr/libexec/mysqld (mysqld 5.5.60-MariaDB) starting as process 20182 ... 190424 13:47:42 InnoDB: The InnoDB memory heap is disabled 190424 13:47:42 InnoDB: Mutexes and rw_locks use GCC atomic builtins 190424 13:47:42 InnoDB: Compressed tables use zlib 1.2.7 190424 13:47:42 InnoDB: Using Linux native AIO 190424 13:47:42 InnoDB: Initializing buffer pool, size = 128.0M 190424 13:47:42 InnoDB: Completed initialization of buffer pool 190424 13:47:42 InnoDB: highest supported file format is Barracuda. 190424 13:47:42 InnoDB: Starting crash recovery from checkpoint LSN=20029414 InnoDB: Restoring possible half-written data pages from the doublewrite buffer... 190424 13:47:42 InnoDB: Starting final batch to recover 6 pages from redo log 190424 13:47:43 InnoDB: Waiting for the background threads to start 190424 13:47:44 Percona XtraDB (http://www.percona.com) 5.5.59-MariaDB-38.11 started; log sequence number 20042705 190424 13:47:44 [Note] Plugin 'FEEDBACK' is disabled. 190424 13:47:44 [Note] Server socket created on IP: '0.0.0.0'. 190424 13:47:44 [Note] Event Scheduler: Loaded 0 events 190424 13:47:44 [Note] /usr/libexec/mysqld: ready for connections. Version: '5.5.60-MariaDB' socket: '/data/mysql/mysql.sock' port: 3306 MariaDB Server 190424 14:00:13 InnoDB: Assertion failure in thread 140319140210432 in file fut0lst.ic line 83 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: http://dev.mysql.com/doc/refman/5.5/en/forcing-innodb-recovery.html InnoDB: about forcing recovery. 190424 14:00:13 [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 http://kb.askmonty.org/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: 5.5.60-MariaDB key_buffer_size=134217728 read_buffer_size=131072 max_used_connections=8 max_threads=153 thread_count=1 It is possible that mysqld could use up to key_buffer_size + (read_buffer_size + sort_buffer_size)*max_threads = 466718 K bytes of memory Hope that's ok; if not, decrease some variables in the equation. Thread pointer: 0x557e04067140 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 = 0x7f9e9881dd80 thread_stack 0x48000 /usr/libexec/mysqld(my_print_stacktrace+0x3d)[0x557e01a99cbd] /usr/libexec/mysqld(handle_fatal_signal+0x515)[0x557e016ae4a5] sigaction.c:0(__restore_rt)[0x7f9eb5c825d0] :0(__GI_raise)[0x7f9eb43ac207] :0(__GI_abort)[0x7f9eb43ad8f8] /usr/libexec/mysqld(+0x2d73b7)[0x557e014e13b7] /usr/libexec/mysqld(+0x6f87d0)[0x557e019027d0] /usr/libexec/mysqld(+0x657ade)[0x557e01861ade] /usr/libexec/mysqld(+0x671153)[0x557e0187b153] /usr/libexec/mysqld(+0x666faf)[0x557e01870faf] /usr/libexec/mysqld(+0x668d94)[0x557e01872d94] /usr/libexec/mysqld(+0x66a6c7)[0x557e018746c7] /usr/libexec/mysqld(+0x60a5a0)[0x557e018145a0] /usr/libexec/mysqld(+0x60b54b)[0x557e0181554b] /usr/libexec/mysqld(_Z19ha_commit_one_phaseP3THDb+0x80)[0x557e016b0ac0] /usr/libexec/mysqld(_Z15ha_commit_transP3THDb+0x356)[0x557e016b1236] /usr/libexec/mysqld(_Z17trans_commit_stmtP3THD+0x1b)[0x557e016443bb] /usr/libexec/mysqld(_Z21mysql_execute_commandP3THD+0x3dc)[0x557e0157c9ec] /usr/libexec/mysqld(_Z11mysql_parseP3THDPcjP12Parser_state+0x125)[0x557e01583445] /usr/libexec/mysqld(_Z16dispatch_command19enum_server_commandP3THDPcj+0x1750)[0x557e015854a0] /usr/libexec/mysqld(_Z24do_handle_one_connectionP3THD+0x1c2)[0x557e01637a22] /usr/libexec/mysqld(handle_one_connection+0x4a)[0x557e01637aca] pthread_create.c:0(start_thread)[0x7f9eb5c7add5] /lib64/libc.so.6(clone+0x6d)[0x7f9eb4473ead] Trying to get some variables. Some pointers may be invalid and cause the dump to abort. Query (0x7f9e6c004c18): UPDATE `ipaddresses` SET `lastSeen`='2019-04-24 14:00:01' WHERE `id`='6098' Connection ID (thread ID): 77 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=on,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=off,table_elimination=on,extended_keys=off 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. 190424 14:00:13 mysqld_safe Number of processes running now: 0 190424 14:00:13 mysqld_safe mysqld restarted 190424 14:00:13 [Note] /usr/libexec/mysqld (mysqld 5.5.60-MariaDB) starting as process 22299 ... 190424 14:00:13 InnoDB: The InnoDB memory heap is disabled 190424 14:00:13 InnoDB: Mutexes and rw_locks use GCC atomic builtins 190424 14:00:13 InnoDB: Compressed tables use zlib 1.2.7 190424 14:00:13 InnoDB: Using Linux native AIO 190424 14:00:13 InnoDB: Initializing buffer pool, size = 128.0M 190424 14:00:13 InnoDB: Completed initialization of buffer pool 190424 14:00:13 InnoDB: highest supported file format is Barracuda. 190424 14:00:13 InnoDB: Starting crash recovery from checkpoint LSN=20053258 InnoDB: Restoring possible half-written data pages from the doublewrite buffer... 190424 14:00:13 InnoDB: Starting final batch to recover 2 pages from redo log 190424 14:00:14 InnoDB: Waiting for the background threads to start 190424 14:00:15 Percona XtraDB (http://www.percona.com) 5.5.59-MariaDB-38.11 started; log sequence number 20062936 190424 14:00:15 [Note] Plugin 'FEEDBACK' is disabled. 190424 14:00:15 [Note] Server socket created on IP: '0.0.0.0'. 190424 14:00:15 [Note] Event Scheduler: Loaded 0 events 190424 14:00:15 [Note] /usr/libexec/mysqld: ready for connections. Version: '5.5.60-MariaDB' socket: '/data/mysql/mysql.sock' port: 3306 MariaDB Server 190424 14:15:13 InnoDB: Assertion failure in thread 140094993282816 in file fut0lst.ic line 83 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: http://dev.mysql.com/doc/refman/5.5/en/forcing-innodb-recovery.html InnoDB: about forcing recovery. 190424 14:15:14 [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 http://kb.askmonty.org/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: 5.5.60-MariaDB key_buffer_size=134217728 read_buffer_size=131072 max_used_connections=3 max_threads=153 thread_count=1 It is possible that mysqld could use up to key_buffer_size + (read_buffer_size + sort_buffer_size)*max_threads = 466718 K bytes of memory Hope that's ok; if not, decrease some variables in the equation. Thread pointer: 0x56260ef072a0 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 = 0x7f6a684f2d80 thread_stack 0x48000 /usr/libexec/mysqld(my_print_stacktrace+0x3d)[0x56260ca60cbd] /usr/libexec/mysqld(handle_fatal_signal+0x515)[0x56260c6754a5] sigaction.c:0(__restore_rt)[0x7f6a6eb535d0] :0(__GI_raise)[0x7f6a6d27d207] :0(__GI_abort)[0x7f6a6d27e8f8] /usr/libexec/mysqld(+0x2d73b7)[0x56260c4a83b7] /usr/libexec/mysqld(+0x6f87d0)[0x56260c8c97d0] /usr/libexec/mysqld(+0x657ade)[0x56260c828ade] /usr/libexec/mysqld(+0x671153)[0x56260c842153] /usr/libexec/mysqld(+0x666faf)[0x56260c837faf] /usr/libexec/mysqld(+0x668d94)[0x56260c839d94] /usr/libexec/mysqld(+0x66a6c7)[0x56260c83b6c7] /usr/libexec/mysqld(+0x60a5a0)[0x56260c7db5a0] /usr/libexec/mysqld(+0x60b54b)[0x56260c7dc54b] /usr/libexec/mysqld(_Z19ha_commit_one_phaseP3THDb+0x80)[0x56260c677ac0] /usr/libexec/mysqld(_Z15ha_commit_transP3THDb+0x356)[0x56260c678236] /usr/libexec/mysqld(_Z17trans_commit_stmtP3THD+0x1b)[0x56260c60b3bb] /usr/libexec/mysqld(_Z21mysql_execute_commandP3THD+0x3dc)[0x56260c5439ec] /usr/libexec/mysqld(_Z11mysql_parseP3THDPcjP12Parser_state+0x125)[0x56260c54a445] /usr/libexec/mysqld(_Z16dispatch_command19enum_server_commandP3THDPcj+0x1750)[0x56260c54c4a0] /usr/libexec/mysqld(_Z24do_handle_one_connectionP3THD+0x1c2)[0x56260c5fea22] /usr/libexec/mysqld(handle_one_connection+0x4a)[0x56260c5feaca] pthread_create.c:0(start_thread)[0x7f6a6eb4bdd5] /lib64/libc.so.6(clone+0x6d)[0x7f6a6d344ead] Trying to get some variables. Some pointers may be invalid and cause the dump to abort. Query (0x7f6a28004c18): UPDATE `ipaddresses` SET `lastSeen`='2019-04-24 14:15:02' WHERE `id`='5956' Connection ID (thread ID): 12 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=on,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=off,table_elimination=on,extended_keys=off 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. 190424 14:15:14 mysqld_safe Number of processes running now: 0 190424 14:15:14 mysqld_safe mysqld restarted 190424 14:15:14 [Note] /usr/libexec/mysqld (mysqld 5.5.60-MariaDB) starting as process 23904 ... 190424 14:15:14 InnoDB: The InnoDB memory heap is disabled 190424 14:15:14 InnoDB: Mutexes and rw_locks use GCC atomic builtins 190424 14:15:14 InnoDB: Compressed tables use zlib 1.2.7 190424 14:15:14 InnoDB: Using Linux native AIO 190424 14:15:14 InnoDB: Initializing buffer pool, size = 128.0M 190424 14:15:14 InnoDB: Completed initialization of buffer pool 190424 14:15:14 InnoDB: highest supported file format is Barracuda. 190424 14:15:14 InnoDB: Starting crash recovery from checkpoint LSN=20068943 InnoDB: Restoring possible half-written data pages from the doublewrite buffer... 190424 14:15:14 InnoDB: Starting final batch to recover 3 pages from redo log 190424 14:15:14 InnoDB: Waiting for the background threads to start 190424 14:15:15 Percona XtraDB (http://www.percona.com) 5.5.59-MariaDB-38.11 started; log sequence number 20101734 190424 14:15:15 [Note] Plugin 'FEEDBACK' is disabled. 190424 14:15:15 [Note] Server socket created on IP: '0.0.0.0'. 190424 14:15:15 [Note] Event Scheduler: Loaded 0 events 190424 14:15:15 [Note] /usr/libexec/mysqld: ready for connections. Version: '5.5.60-MariaDB' socket: '/data/mysql/mysql.sock' port: 3306 MariaDB Server 190424 14:15:49 InnoDB: Assertion failure in thread 140184444618496 in file fut0lst.ic line 83 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: http://dev.mysql.com/doc/refman/5.5/en/forcing-innodb-recovery.html InnoDB: about forcing recovery. 190424 14:15:49 [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 http://kb.askmonty.org/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: 5.5.60-MariaDB key_buffer_size=134217728 read_buffer_size=131072 max_used_connections=2 max_threads=153 thread_count=1 It is possible that mysqld could use up to key_buffer_size + (read_buffer_size + sort_buffer_size)*max_threads = 466718 K bytes of memory Hope that's ok; if not, decrease some variables in the equation. Thread pointer: 0x5642b71d5cb0 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 = 0x7f7f3c063d80 thread_stack 0x48000 /usr/libexec/mysqld(my_print_stacktrace+0x3d)[0x5642b4703cbd] /usr/libexec/mysqld(handle_fatal_signal+0x515)[0x5642b43184a5] sigaction.c:0(__restore_rt)[0x7f7f415375d0] :0(__GI_raise)[0x7f7f3fc61207] :0(__GI_abort)[0x7f7f3fc628f8] /usr/libexec/mysqld(+0x2d73b7)[0x5642b414b3b7] /usr/libexec/mysqld(+0x6f87d0)[0x5642b456c7d0] /usr/libexec/mysqld(+0x657ade)[0x5642b44cbade] /usr/libexec/mysqld(+0x671153)[0x5642b44e5153] /usr/libexec/mysqld(+0x666faf)[0x5642b44dafaf] /usr/libexec/mysqld(+0x668d94)[0x5642b44dcd94] /usr/libexec/mysqld(+0x66a6c7)[0x5642b44de6c7] /usr/libexec/mysqld(+0x60a5a0)[0x5642b447e5a0] /usr/libexec/mysqld(+0x60b54b)[0x5642b447f54b] /usr/libexec/mysqld(_Z19ha_commit_one_phaseP3THDb+0x80)[0x5642b431aac0] /usr/libexec/mysqld(_Z15ha_commit_transP3THDb+0x356)[0x5642b431b236] /usr/libexec/mysqld(_Z17trans_commit_stmtP3THD+0x1b)[0x5642b42ae3bb] /usr/libexec/mysqld(_Z21mysql_execute_commandP3THD+0x3dc)[0x5642b41e69ec] /usr/libexec/mysqld(_Z11mysql_parseP3THDPcjP12Parser_state+0x125)[0x5642b41ed445] /usr/libexec/mysqld(_Z16dispatch_command19enum_server_commandP3THDPcj+0x1750)[0x5642b41ef4a0] /usr/libexec/mysqld(_Z24do_handle_one_connectionP3THD+0x1c2)[0x5642b42a1a22] /usr/libexec/mysqld(handle_one_connection+0x4a)[0x5642b42a1aca] pthread_create.c:0(start_thread)[0x7f7f4152fdd5] /lib64/libc.so.6(clone+0x6d)[0x7f7f3fd28ead] Trying to get some variables. Some pointers may be invalid and cause the dump to abort. Query (0x7f7ef802c148): UPDATE `users` SET `lastActivity`='2019-04-24 12:15:49' WHERE `id`='1' Connection ID (thread ID): 8 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=on,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=off,table_elimination=on,extended_keys=off 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. 190424 14:15:50 mysqld_safe Number of processes running now: 0 190424 14:15:50 mysqld_safe mysqld restarted 190424 14:15:50 [Note] /usr/libexec/mysqld (mysqld 5.5.60-MariaDB) starting as process 24194 ... 190424 14:15:50 InnoDB: The InnoDB memory heap is disabled 190424 14:15:50 InnoDB: Mutexes and rw_locks use GCC atomic builtins 190424 14:15:50 InnoDB: Compressed tables use zlib 1.2.7 190424 14:15:50 InnoDB: Using Linux native AIO 190424 14:15:50 InnoDB: Initializing buffer pool, size = 128.0M 190424 14:15:50 InnoDB: Completed initialization of buffer pool 190424 14:15:50 InnoDB: highest supported file format is Barracuda. InnoDB: The log sequence number in ibdata files does not match InnoDB: the log sequence number in the ib_logfiles! InnoDB: Restoring possible half-written data pages from the doublewrite buffer... 190424 14:15:50 InnoDB: Waiting for the background threads to start 190424 14:15:51 Percona XtraDB (http://www.percona.com) 5.5.59-MariaDB-38.11 started; log sequence number 20103231 190424 14:15:51 [Note] Plugin 'FEEDBACK' is disabled. 190424 14:15:51 [Note] Server socket created on IP: '0.0.0.0'. 190424 14:15:51 [Note] Event Scheduler: Loaded 0 events 190424 14:15:51 [Note] /usr/libexec/mysqld: ready for connections. Version: '5.5.60-MariaDB' socket: '/data/mysql/mysql.sock' port: 3306 MariaDB Server 190424 14:16:48 InnoDB: Assertion failure in thread 140089083143936 in file fut0lst.ic line 83 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: http://dev.mysql.com/doc/refman/5.5/en/forcing-innodb-recovery.html InnoDB: about forcing recovery. 190424 14:16:48 [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 http://kb.askmonty.org/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: 5.5.60-MariaDB key_buffer_size=134217728 read_buffer_size=131072 max_used_connections=2 max_threads=153 thread_count=1 It is possible that mysqld could use up to key_buffer_size + (read_buffer_size + sort_buffer_size)*max_threads = 466718 K bytes of memory Hope that's ok; if not, decrease some variables in the equation. Thread pointer: 0x562dd66b2240 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 = 0x7f6908099d80 thread_stack 0x48000 /usr/libexec/mysqld(my_print_stacktrace+0x3d)[0x562dd4390cbd] /usr/libexec/mysqld(handle_fatal_signal+0x515)[0x562dd3fa54a5] sigaction.c:0(__restore_rt)[0x7f690bbf85d0] :0(__GI_raise)[0x7f690a322207] :0(__GI_abort)[0x7f690a3238f8] /usr/libexec/mysqld(+0x2d73b7)[0x562dd3dd83b7] /usr/libexec/mysqld(+0x6f87d0)[0x562dd41f97d0] /usr/libexec/mysqld(+0x657ade)[0x562dd4158ade] /usr/libexec/mysqld(+0x671153)[0x562dd4172153] /usr/libexec/mysqld(+0x666faf)[0x562dd4167faf] /usr/libexec/mysqld(+0x668d94)[0x562dd4169d94] /usr/libexec/mysqld(+0x66a6c7)[0x562dd416b6c7] /usr/libexec/mysqld(+0x60a5a0)[0x562dd410b5a0] /usr/libexec/mysqld(+0x60b54b)[0x562dd410c54b] /usr/libexec/mysqld(_Z19ha_commit_one_phaseP3THDb+0x80)[0x562dd3fa7ac0] /usr/libexec/mysqld(_Z15ha_commit_transP3THDb+0x356)[0x562dd3fa8236] /usr/libexec/mysqld(_Z17trans_commit_stmtP3THD+0x1b)[0x562dd3f3b3bb] /usr/libexec/mysqld(_Z21mysql_execute_commandP3THD+0x3dc)[0x562dd3e739ec] /usr/libexec/mysqld(_Z11mysql_parseP3THDPcjP12Parser_state+0x125)[0x562dd3e7a445] /usr/libexec/mysqld(_Z16dispatch_command19enum_server_commandP3THDPcj+0x1750)[0x562dd3e7c4a0] /usr/libexec/mysqld(_Z24do_handle_one_connectionP3THD+0x1c2)[0x562dd3f2ea22] /usr/libexec/mysqld(handle_one_connection+0x4a)[0x562dd3f2eaca] pthread_create.c:0(start_thread)[0x7f690bbf0dd5] /lib64/libc.so.6(clone+0x6d)[0x7f690a3e9ead] Trying to get some variables. Some pointers may be invalid and cause the dump to abort. Query (0x7f68c8004c18): UPDATE `users` SET `lastActivity`='2019-04-24 12:16:48' WHERE `id`='1' Connection ID (thread ID): 15 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=on,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=off,table_elimination=on,extended_keys=off 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. 190424 14:16:48 mysqld_safe Number of processes running now: 0 190424 14:16:48 mysqld_safe mysqld restarted 190424 14:16:49 [Note] /usr/libexec/mysqld (mysqld 5.5.60-MariaDB) starting as process 24488 ... 190424 14:16:49 InnoDB: The InnoDB memory heap is disabled 190424 14:16:49 InnoDB: Mutexes and rw_locks use GCC atomic builtins 190424 14:16:49 InnoDB: Compressed tables use zlib 1.2.7 190424 14:16:49 InnoDB: Using Linux native AIO 190424 14:16:49 InnoDB: Initializing buffer pool, size = 128.0M 190424 14:16:49 InnoDB: Completed initialization of buffer pool 190424 14:16:49 InnoDB: highest supported file format is Barracuda. 190424 14:16:49 InnoDB: Starting crash recovery from checkpoint LSN=20104363 InnoDB: Restoring possible half-written data pages from the doublewrite buffer... 190424 14:16:49 InnoDB: Starting final batch to recover 4 pages from redo log 190424 14:16:49 InnoDB: Waiting for the background threads to start 190424 14:16:50 Percona XtraDB (http://www.percona.com) 5.5.59-MariaDB-38.11 started; log sequence number 20105327 190424 14:16:50 [Note] Plugin 'FEEDBACK' is disabled. 190424 14:16:50 [Note] Server socket created on IP: '0.0.0.0'. 190424 14:16:50 [Note] Event Scheduler: Loaded 0 events 190424 14:16:50 [Note] /usr/libexec/mysqld: ready for connections. Version: '5.5.60-MariaDB' socket: '/data/mysql/mysql.sock' port: 3306 MariaDB Server