Details
-
Bug
-
Status: Closed (View Workflow)
-
Major
-
Resolution: Fixed
-
10.0.24
-
None
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
|
|
Attachments
Issue Links
- relates to
-
-
- Closed
-
-
-
- Closed
-
Activity
Hi,
Customer replied that
"There were no monitoring tools, but there were no capacity shortfalls at the time."
Regards,
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.
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.
Closing since we got no feedback since February. We can consider that the past maintenance released fixed this issue.
I'll ask them and will get back to you.