[MDEV-14970] MariaDB crashed with signal 11 and Aria table Created: 2018-01-17  Updated: 2020-08-25  Resolved: 2018-04-24

Status: Closed
Project: MariaDB Server
Component/s: Storage Engine - Aria
Affects Version/s: 10.0.24
Fix Version/s: 10.0.34

Type: Bug Priority: Major
Reporter: Nilnandan Joshi Assignee: Michael Widenius
Resolution: Fixed Votes: 1
Labels: None

Issue Links:
Relates
relates to MDEV-15237 "Can't write; duplicate key in table"... Closed
relates to MDEV-15304 Server crash in print_keydup_error / ... Closed

 Description    

180111 10:24:15 [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: 10.0.24-MariaDB
 
key_buffer_size=134217728
 
read_buffer_size=131072
 
max_used_connections=201
 
max_threads=202
 
thread_count=41
 
It is possible that mysqld could use up to
 
key_buffer_size + (read_buffer_size + sort_buffer_size)*max_threads = 574598 K bytes of memory
 
Hope that's ok; if not, decrease some variables in the equation.
 
 
 
Thread pointer: 0x0x7f22483a2008
 
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 = 0x7f2257bfed30 thread_stack 0x48000
 
180111 10:24:16 [ERROR] Got error 175 when reading table './dbsafer_log_2018_01/db_query_11'
 
/usr/sbin/mysqld(my_print_stacktrace+0x2b)[0xb8d0db]
 
/usr/sbin/mysqld(handle_fatal_signal+0x398)[0x737ac8]
 
/lib64/libpthread.so.0(+0xf7e0)[0x7f22882a47e0]
 
/usr/sbin/mysqld(_Z10key_unpackP6StringP5TABLEP6st_key+0x40)[0x7d3fe0]
 
/usr/sbin/mysqld(_Z18print_keydup_errorP5TABLEP6st_keyPKcm+0x87)[0x73d4b7]
 
/usr/sbin/mysqld(_ZN7handler11print_errorEim+0x255)[0x73dc35]
 
/usr/sbin/mysqld(_Z12write_recordP3THDP5TABLEP12st_copy_info+0x112)[0x5c71a2]
 
/usr/sbin/mysqld(_Z12mysql_insertP3THDP10TABLE_LISTR4ListI4ItemERS3_IS5_ES6_S6_15enum_duplicatesb+0xbd2)[0x5cc2e2]
 
/usr/sbin/mysqld(_Z21mysql_execute_commandP3THD+0x4627)[0x5e2fd7]
 
/usr/sbin/mysqld[0x5e54e7]
 
/usr/sbin/mysqld(_Z16dispatch_command19enum_server_commandP3THDPcj+0x1d0d)[0x5e795d]
 
/usr/sbin/mysqld(_Z24do_handle_one_connectionP3THD+0x453)[0x6a5a33]
 
/usr/sbin/mysqld(handle_one_connection+0x42)[0x6a5b02]
 
/lib64/libpthread.so.0(+0x7aa1)[0x7f228829caa1]
 
/lib64/libc.so.6(clone+0x6d)[0x7f22869b593d]
 
 
 
Trying to get some variables.
 
Some pointers may be invalid and cause the dump to abort.
 
Query (0x7f224b84f020): is an invalid pointer
 
Connection ID (thread ID): 32765079
 
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=on,exists_to_in=on



 Comments   
Comment by Daniel Black [ 2018-01-17 ]

$ perror 175
MySQL error code 175: File too short; Expected more data in file

Did you run out of disk space?

What are the file sizes of ./dbsafer_log_2018_01/db_query_11* ?

Comment by Elena Stepanova [ 2018-01-19 ]

niljoshi, is it recurring problem, or was it a one-time occurrence? If it happened more than once, was it always accompanied with the error 175? Please also answer Daniel's questions above.

Comment by Nilnandan Joshi [ 2018-01-19 ]

Hi Elena/Daniel,

Sorry for late reply. It was one time occurrence and before we capture any data they restored
those tables from the backup so now we don't have any way to capture the size of old data files where we can check about sizes. Please let me know if we can do anything else in this case.

Thanks and Regards,

Comment by Elena Stepanova [ 2018-01-19 ]

Do they have some sort of disk space monitor which would still have historical data (for the moment of the crash), to see if there was a lack of space back then?

Comment by Nilnandan Joshi [ 2018-01-19 ]

I'll ask them and will get back to you.

Comment by Nilnandan Joshi [ 2018-01-22 ]

Hi,

Customer replied that
"There were no monitoring tools, but there were no capacity shortfalls at the time."

Regards,

Comment by Michael Widenius [ 2018-01-23 ]

I have no way to repeat the error. However the only logical reason for the crash is that the storage engine somehow returns the wrong key to be used by print_keydup_error().

I have now made a fix that should ensure that print_keydup_error() will never get a reference to an unknown key.

If the storage engine in the future reports a wrong key, the error will be duplicate key error with UNKNOWN key. If this happens, please try to create a test case and we will fix the storage engine code that causes this!

Please comment if this is fixed in the next release so that we can close this issue.

Comment by Elena Stepanova [ 2018-02-13 ]

I have a test case which causes the same crash with RocksDB – and indeed, now it returns ER_DUP_KEY: MDEV-15304
Probably it's somewhat better for production than a crash, but it's highly confusing, because the error happens on a table which has no reason whatsoever to produce a duplicate key error.

Comment by Julien Fritsch [ 2018-04-24 ]

Closing since we got no feedback since February. We can consider that the past maintenance released fixed this issue.

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