[MDEV-5395] after 2+ weeks server crashed; several tables injured Created: 2013-12-05  Updated: 2018-08-01  Due: 2014-01-12  Resolved: 2014-01-14

Status: Closed
Project: MariaDB Server
Component/s: None
Affects Version/s: 5.5.34
Fix Version/s: None

Type: Bug Priority: Major
Reporter: Michael Shestero Assignee: Elena Stepanova
Resolution: Incomplete Votes: 0
Labels: None
Environment:

5.5.34-MariaDB-1~precise from you repo. for Ubuntu 12.04
uname -a
Linux Ubuntu-1110-oneiric-64-minimal 3.2.0-55-generic #85-Ubuntu SMP Wed Oct 2 12:29:27 UTC 2013 x86_64 x86_64 x86_64 GNU/Linux
but indeed it is Ubuntu 12.04.3 LTS (this written then I started terminal session automatically upgraded).


 Description   

After working more than 15 days the MariaDB crashed, several tables injuried.
The mysqld was restarted. It happened only about 7-8 hours ago, but now I see that mysqld eat all 32 Gb RAM and all the swap (memory leak??).

Here is pieces from error log:

131205  9:21:01 [ERROR] mysqld: Table './gtk1h/main2011' is marked as crashed and last (automatic?) repair failed
 
131205  9:21:01 [ERROR] mysqld: Table './gtk1h/main2012_' is marked as crashed and last (automatic?) repair failed
 
131205  9:21:01 [ERROR] mysqld: Table './gtk1h/main2010' is marked as crashed and last (automatic?) repair failed
 
131205  9:21:01 [ERROR] mysqld: Table './gtk1h/main2011' is marked as crashed and last (automatic?) repair failed
 
131205  9:21:01 [ERROR] mysqld: Table './gtk1h/main2012_' is marked as crashed and last (automatic?) repair failed
 
131205  9:40:07 [ERROR] mysqld got signal 11 ;
 
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.34-MariaDB-1~precise
 
key_buffer_size=25769803776
 
read_buffer_size=131072
 
max_used_connections=13
 
max_threads=52
 
thread_count=5
 
It is possible that mysqld could use up to 
key_buffer_size + (read_buffer_size + sort_buffer_size)*max_threads = 26025358 K  bytes of memory
 
Hope that's ok; if not, decrease some variables in the equation.
 
 
 
Thread pointer: 0x0x7f56d24a9000
 
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 = 0x7f5ce3d54e10 thread_stack 0x30000
 
(my_addr_resolve failure: fork)
 
/usr/sbin/mysqld(my_print_stacktrace+0x2b) [0x7f5ce64d58cb]
 
/usr/sbin/mysqld(handle_fatal_signal+0x471) [0x7f5ce60fc1d1]
 
/lib/x86_64-linux-gnu/libpthread.so.0(+0xfcb0) [0x7f5ce4fa1cb0]
 
/usr/sbin/mysqld(Query_cache::unlink_table(Query_cache_block_table*)+0x6a) [0x7f5ce5f7ec9a]
 
/usr/sbin/mysqld(Query_cache::register_all_tables(THD*, Query_cache_block*, TABLE_LIST*, unsigned int)+0x6a) [0x7f5ce5f816aa]
 
/usr/sbin/mysqld(Query_cache::store_query(THD*, TABLE_LIST*)+0x413) [0x7f5ce5f829e3]
 
/usr/sbin/mysqld(+0x380a82) [0x7f5ce5fb0a82]
 
/usr/sbin/mysqld(mysql_execute_command(THD*)+0xe85) [0x7f5ce5fb8685]
 
/usr/sbin/mysqld(+0x38e9c7) [0x7f5ce5fbe9c7]
 
/usr/sbin/mysqld(dispatch_command(enum_server_command, THD*, char*, unsigned int)+0x2276) [0x7f5ce5fc1626]
 
/usr/sbin/mysqld(do_handle_one_connection(THD*)+0x133) [0x7f5ce607e693]
 
/usr/sbin/mysqld(handle_one_connection+0x51) [0x7f5ce607e7f1]
 
/lib/x86_64-linux-gnu/libpthread.so.0(+0x7e9a) [0x7f5ce4f99e9a]
 
/lib/x86_64-linux-gnu/libc.so.6(clone+0x6d) [0x7f5ce40913fd]
 
 
 
Trying to get some variables.
 
Some pointers may be invalid and cause the dump to abort.
 
Query (0x7f56d4c0e018): is an invalid pointer
 
Connection ID (thread ID): 129320
 
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.
 
131205 09:40:08 mysqld_safe Number of processes running now: 0
 
131205 09:40:08 mysqld_safe mysqld restarted
 
131205  9:40:11 [Note] Plugin 'InnoDB' is disabled.
 
131205  9:40:11 [Note] Plugin 'FEEDBACK' is disabled.
 
131205  9:40:11 [Note] Server socket created on IP: '127.0.0.1'.
 
131205  9:40:12 [Note] Event Scheduler: Loaded 1 event
 
131205  9:40:12 [Note] /usr/sbin/mysqld: ready for connections.
 
Version: '5.5.34-MariaDB-1~precise'  socket: '/var/run/mysqld/mysqld.sock'  port: 3306  mariadb.org binary distribution
 
131205  9:40:12 [ERROR] mysqld: Table './gtk1/customs_audit2013' is marked as crashed and should be repaired
 
131205  9:40:12 [Warning] Checking table:   './gtk1/customs_audit2013'
 
....



 Comments   
Comment by Elena Stepanova [ 2013-12-10 ]

Hi,

according to the log fragment, you have a very big value for key_buffer_size. Like, really huge: key_buffer_size=25769803776. It's 24 Gb, right?
Was it intentional? How much memory total do you have in your system so that you can afford that?
With this level of generosity, it doesn't seem really surprising that MariaDB takes 32 Gb in total, there are other buffers as well.

Otherwise, we do have one open bug with a suspected memory leak, MDEV-4974, which is currently being investigated, but at this point it's impossible to say if you encountered the same problem.

For the crash, did it happen again? You don't have general log enabled by any chance, do you?

Comment by Elena Stepanova [ 2014-01-14 ]

Closing for now as incomplete, please comment if you have more information to re-open the bug

Comment by Evgenii Terechkov [ 2017-06-12 ]

I have similar (a)periodic issue (correct me if Im wrong) with newer version of mariadb:

root@zabbix ~ # LC_ALL=C journalctl -u mysqld |grep status=
 
Apr 06 15:10:24 zabbix.optibit.ru systemd[1]: mysqld.service: Main process exited, code=killed, status=11/SEGV
 
May 08 15:24:39 zabbix.optibit.ru systemd[1]: mysqld.service: Main process exited, code=killed, status=11/SEGV
 
May 20 10:42:22 zabbix.optibit.ru systemd[1]: mysqld.service: Main process exited, code=killed, status=11/SEGV
 
May 23 14:25:27 zabbix.optibit.ru systemd[1]: mysqld.service: Main process exited, code=killed, status=11/SEGV
 
May 27 16:12:38 zabbix.optibit.ru systemd[1]: mysqld.service: Main process exited, code=killed, status=11/SEGV
 
May 29 01:24:53 zabbix.optibit.ru systemd[1]: mysqld.service: Main process exited, code=killed, status=11/SEGV
 
Jun 11 16:53:20 zabbix.optibit.ru systemd[1]: mysqld.service: Main process exited, code=killed, status=11/SEGV

Log piece for latest case:

Jun 11 16:53:19 zabbix mysqld 170611 16:53:19 [ERROR] mysqld got signal 11 ;
 
Jun 11 16:53:19 zabbix mysqld This could be because you hit a bug. It is also possible that this binary
 
Jun 11 16:53:19 zabbix mysqld or one of the libraries it was linked against is corrupt, improperly built,
 
Jun 11 16:53:19 zabbix mysqld or misconfigured. This error can also be caused by malfunctioning hardware.
 
Jun 11 16:53:19 zabbix mysqld To report this bug, see https://mariadb.com/kb/en/reporting-bugs
 
Jun 11 16:53:19 zabbix mysqld We will try our best to scrape up some info that will hopefully help
 
Jun 11 16:53:19 zabbix mysqld diagnose the problem, but since we have already crashed, 
Jun 11 16:53:19 zabbix mysqld something is definitely wrong and this may fail.
 
Jun 11 16:53:19 zabbix mysqld Server version: 10.1.23-MariaDB-alt1.S1
 
Jun 11 16:53:19 zabbix mysqld key_buffer_size=16777216
 
Jun 11 16:53:19 zabbix mysqld read_buffer_size=262144
 
Jun 11 16:53:19 zabbix mysqld max_used_connections=94
 
Jun 11 16:53:19 zabbix mysqld max_threads=127
 
Jun 11 16:53:19 zabbix mysqld thread_count=81
 
Jun 11 16:53:19 zabbix mysqld It is possible that mysqld could use up to 
Jun 11 16:53:19 zabbix mysqld key_buffer_size + (read_buffer_size + sort_buffer_size)*max_threads = 116511 K  bytes of memory
 
Jun 11 16:53:19 zabbix mysqld Hope that's ok; if not, decrease some variables in the equation.
 
Jun 11 16:53:19 zabbix mysqld Thread pointer: 0x7f777fea8008
 
Jun 11 16:53:19 zabbix mysqld Attempting backtrace. You can use the following information to find out
 
Jun 11 16:53:19 zabbix mysqld where mysqld died. If you see no messages after this, something went
 
Jun 11 16:53:19 zabbix mysqld terribly wrong...
 
Jun 11 16:53:20 zabbix mysqld stack_bottom = 0x7f777266dcb8 thread_stack 0x30000
 
Jun 11 16:53:20 zabbix mysqld (my_addr_resolve failure: fork)
 
Jun 11 16:53:20 zabbix mysqld /usr/sbin/mysqld(my_print_stacktrace+0x2e) [0x563c0c2bac8e]
 
Jun 11 16:53:20 zabbix mysqld /usr/sbin/mysqld(handle_fatal_signal+0x3bd) [0x563c0be0068d]
 
Jun 11 16:53:20 zabbix mysqld /lib64/libpthread.so.0(+0x110a0) [0x7f78f0e240a0]
 
Jun 11 16:53:20 zabbix mysqld /usr/sbin/mysqld(Query_cache::unlink_table(Query_cache_block_table*)+0x8) [0x563c0bc37878]
 
Jun 11 16:53:20 zabbix mysqld /usr/sbin/mysqld(Query_cache::register_all_tables(THD*, Query_cache_block*, TABLE_LIST*, unsigned int)+0x99) [0x5
 
63c0bc38979]
 
Jun 11 16:53:20 zabbix mysqld /usr/sbin/mysqld(Query_cache::store_query(THD*, TABLE_LIST*)+0x42b) [0x563c0bc3a7ab]
 
Jun 11 16:53:20 zabbix mysqld /usr/sbin/mysqld(+0x3ff541) [0x563c0bc6a541]
 
Jun 11 16:53:20 zabbix mysqld /usr/sbin/mysqld(mysql_execute_command(THD*)+0x6604) [0x563c0bc77564]
 
Jun 11 16:53:20 zabbix mysqld /usr/sbin/mysqld(mysql_parse(THD*, char*, unsigned int, Parser_state*)+0x311) [0x563c0bc79ef1]
 
Jun 11 16:53:20 zabbix mysqld /usr/sbin/mysqld(dispatch_command(enum_server_command, THD*, char*, unsigned int)+0x23f9) [0x563c0bc7d209]
 
Jun 11 16:53:20 zabbix mysqld /usr/sbin/mysqld(do_command(THD*)+0x155) [0x563c0bc7d915]
 
Jun 11 16:53:20 zabbix mysqld /usr/sbin/mysqld(do_handle_one_connection(THD*)+0x1d2) [0x563c0bd47d72]
 
Jun 11 16:53:20 zabbix mysqld /usr/sbin/mysqld(handle_one_connection+0x40) [0x563c0bd47ed0]
 
Jun 11 16:53:20 zabbix mysqld /lib64/libpthread.so.0(+0x7404) [0x7f78f0e1a404]
 
Jun 11 16:53:20 zabbix mysqld /lib64/libc.so.6(clone+0x5f) [0x7f78f045d7bf]
 
Jun 11 16:53:20 zabbix mysqld Trying to get some variables.
 
Jun 11 16:53:20 zabbix mysqld Some pointers may be invalid and cause the dump to abort.
 
Jun 11 16:53:20 zabbix mysqld Query (0x7f777cbf7020): is an invalid pointer
 
Jun 11 16:53:20 zabbix mysqld Connection ID (thread ID): 1315201
 
Jun 11 16:53:20 zabbix mysqld Status: NOT_KILLED
 
Jun 11 16:53:20 zabbix mysqld 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,loos
 
escan=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=on,exists_to_in=on,orderby_uses_equalities=off
 
Jun 11 16:53:20 zabbix mysqld The manual page at http://dev.mysql.com/doc/mysql/en/crashing.html contains
 
Jun 11 16:53:20 zabbix mysqld information that should help you find out what is causing the crash.
 
Jun 11 16:53:20 zabbix mysqld We think the query pointer is invalid, but we will try to print it anyway. 
Jun 11 16:53:20 zabbix mysqld Query: SELECT MAX(g.gui_access) AS gui_access FROM usrgrp g,users_groups ug WHERE ug.userid='2' AND g.usrgrpid=ug
 
.usrgrpid
 
Jun 11 16:53:20 zabbix systemd[1]: mysqld.service: Main process exited, code=killed, status=11/SEGV
 
Jun 11 16:53:20 zabbix systemd[1]: mysqld.service: Unit entered failed state.
 
Jun 11 16:53:20 zabbix systemd[1]: mysqld.service: Failed with result 'signal'.

I will be happy to drop additional information as needed.

Generated at Thu Feb 08 07:04:04 UTC 2024 using Jira 8.20.16#820016-sha1:9d11dbea5f4be3d4cc21f03a88dd11d8c8687422.