[MDEV-4780] Crash while running SET GLOBAL key_cache_segments = 64 - JIRA

Details

Type: Bug
Status: Closed
Priority: Major
Resolution: Won't Fix
Affects Version/s: 10.0.3, 5.5.31, 5.3.12
Fix Version/s: N/A
Component/s: Admin statements
Labels:
None

Description

Hello and thank you for mariadb-5.3.12-Linux-x86_64.tar.gz

I added a comment in https://mariadb.atlassian.net/browse/MDEV-4409 mentioning two crashes I had today while running "SET GLOBAL key_cache_segments = 64;" on mariadb-5.3.12-Linux-x86_64.tar.gz on RHEL5. Vladislav Vaintroub pointed me at https://bugs.launchpad.net/maria/+bug/1008293 and I found the following changes

http://bazaar.launchpad.net/~maria-captains/maria/5.2/revision/3159
http://bazaar.launchpad.net/~maria-captains/maria/5.2/revision/3115

I have a RQG reproducer

# cat 3.yy
query_init:
  SET GLOBAL key_buffer_size = 1024*1024;
thread1:
  SET GLOBAL key_cache_segments = _digit;

query:
  REPLACE INTO E(col_int_key, col_datetime_key) VALUES(1, NOW());

# End of RQG grammar

# Run as
perl ./runall.pl \
--grammar=3.yy \
--duration=10 \
--queries=1M \
--threads=2 \
--basedir=<your basedir> \
--vardir=<your vardir>

Produces:

130711 20:08:18 [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.3.12-MariaDB-log
key_buffer_size=1048575
read_buffer_size=131072
max_used_connections=3
max_threads=152
thread_count=3
connection_count=3
It is possible that mysqld could use up to
key_buffer_size + (read_buffer_size + sort_buffer_size)*max_threads = 61369 K  bytes of memory
Hope that's ok; if not, decrease some variables in the equation.

Thread pointer: 0x0x27d5c10
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 = 0x7f7c0b794e68 thread_stack 0x48000
/bin/mysqld(my_print_stacktrace+0x2e) [0x998a1e]
/bin/mysqld(handle_fatal_signal+0x3f9) [0x71ede9]
/lib64/libpthread.so.0() [0x3c1c60f500]
/bin/mysqld() [0x99ecc7]
/bin/mysqld(simple_key_cache_read+0x1bc) [0x99f3fc]
/bin/mysqld() [0x99f609]
/bin/mysqld(_mi_fetch_keypage+0x48) [0x7e1ff8]
/bin/mysqld() [0x7c64a6]
/bin/mysqld() [0x7c666b]
/bin/mysqld(_mi_ck_real_write_btree+0x60) [0x7c68e0]
/bin/mysqld(_mi_ck_write_btree+0x72) [0x7c6992]
/bin/mysqld(mi_write+0x320) [0x7c6ee0]
/bin/mysqld(handler::ha_write_row(unsigned char*)+0x37) [0x7137f7]
/bin/mysqld(write_record(THD*, st_table*, st_copy_info*)+0x34e) [0x691c4e]
/bin/mysqld(mysql_insert(THD*, TABLE_LIST*, List<Item>&, List<List<Item> >&, List<Item>&, List<Item>&, enum_duplicates, bool)+0xa31) [0x696891]
/bin/mysqld(mysql_execute_command(THD*)+0xad8) [0x6048c8]
/bin/mysqld(mysql_parse(THD*, char*, unsigned int, char const**)+0x299) [0x60a629]
/bin/mysqld(dispatch_command(enum_server_command, THD*, char*, unsigned int)+0xdf9) [0x60b879]
/bin/mysqld(do_command(THD*)+0x101) [0x60c0b1]
/bin/mysqld(handle_one_connection+0xfd) [0x5fd7bd]
/lib64/libpthread.so.0() [0x3c1c607851]
/lib64/libc.so.6(clone+0x6d) [0x3c1c2e767d]

Trying to get some variables.
Some pointers may be invalid and cause the dump to abort.
Query (0x7f7bc0004c48): REPLACE INTO E(col_int_key, col_datetime_key) VALUES(1, NOW())
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,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

With --debug

*** glibc detected *** /bin/mysqld: free(): corrupted unsorted chunks: 0x00007f43e800e450 ***
======= Backtrace: =========
/lib64/libc.so.6[0x3c1c275366]
/lib64/libc.so.6[0x3c1c277e93]
/bin/mysqld[0x99ef65]
/bin/mysqld[0x99d300]
/bin/mysqld[0x99d5a7]
/bin/mysqld(repartition_key_cache+0x14)[0x99d654]
/bin/mysqld(_Z24ha_repartition_key_cacheP12st_key_cache+0x6a)[0x70feba]
/bin/mysqld(_ZN22sys_var_key_cache_long6updateEP3THDP7set_var+0x111)[0x6102f1]
/bin/mysqld(_ZN7set_var6updateEP3THD+0x4e)[0x60dc1e]
/bin/mysqld(_Z17sql_set_variablesP3THDP4ListI12set_var_baseE+0x7d)[0x619ced]
/bin/mysqld(_Z21mysql_execute_commandP3THD+0x1fc6)[0x605db6]
/bin/mysqld(_Z11mysql_parseP3THDPcjPPKc+0x299)[0x60a629]
/bin/mysqld(_Z16dispatch_command19enum_server_commandP3THDPcj+0xdf9)[0x60b879]
/bin/mysqld(_Z10do_commandP3THD+0x101)[0x60c0b1]
/bin/mysqld(handle_one_connection+0xfd)[0x5fd7bd]
/lib64/libpthread.so.0[0x3c1c607851]
/lib64/libc.so.6(clone+0x6d)[0x3c1c2e767d]

*** glibc detected *** /bin/mysqld: malloc(): memory corruption: 0x00007f43e808cb80 ***
======= Backtrace: =========
/lib64/libc.so.6[0x3c1c275366]
/lib64/libc.so.6[0x3c1c278de4]
/lib64/libc.so.6(__libc_malloc+0x71)[0x3c1c279b91]
/lib64/libc.so.6(__backtrace_symbols+0x119)[0x3c1c2fd899]
/bin/mysqld(my_print_stacktrace+0x50)[0x998a40]
/bin/mysqld(handle_fatal_signal+0x3f9)[0x71ede9]
/lib64/libpthread.so.0[0x3c1c60f500]
/lib64/libc.so.6(gsignal+0x35)[0x3c1c2328a5]
/lib64/libc.so.6(abort+0x175)[0x3c1c234085]
/lib64/libc.so.6[0x3c1c26fa37]
/lib64/libc.so.6[0x3c1c275366]
/lib64/libc.so.6[0x3c1c277e93]
/bin/mysqld[0x99ef65]
/bin/mysqld[0x99d300]
/bin/mysqld[0x99d5a7]
/bin/mysqld(repartition_key_cache+0x14)[0x99d654]
/bin/mysqld(_Z24ha_repartition_key_cacheP12st_key_cache+0x6a)[0x70feba]
/bin/mysqld(_ZN22sys_var_key_cache_long6updateEP3THDP7set_var+0x111)[0x6102f1]
/bin/mysqld(_ZN7set_var6updateEP3THD+0x4e)[0x60dc1e]
/bin/mysqld(_Z17sql_set_variablesP3THDP4ListI12set_var_baseE+0x7d)[0x619ced]
/bin/mysqld(_Z21mysql_execute_commandP3THD+0x1fc6)[0x605db6]
/bin/mysqld(_Z11mysql_parseP3THDPcjPPKc+0x299)[0x60a629]
/bin/mysqld(_Z16dispatch_command19enum_server_commandP3THDPcj+0xdf9)[0x60b879]
/bin/mysqld(_Z10do_commandP3THD+0x101)[0x60c0b1]
/bin/mysqld(handle_one_connection+0xfd)[0x5fd7bd]
/lib64/libpthread.so.0[0x3c1c607851]
/lib64/libc.so.6(clone+0x6d)[0x3c1c2e767d]

Gliffy Diagrams

Attachments

Issue Links

links to

related commit, not a complete fix

Activity

Ascending order - Click to sort in descending order

Hide

Permalink

Vladislav Vaintroub added a comment - 2013-07-11 20:46

How much do you need key cache segments to be dynamic variable? We can either continue to patch lke in https://bugs.launchpad.net/maria/+bug/1008293 , or if we're frank to ourselves, and admit that changing such things is hard (and does not bring much benefit) we make it static, fixed at the server startup,

Show

Vladislav Vaintroub added a comment - 2013-07-11 20:46 How much do you need key cache segments to be dynamic variable? We can either continue to patch lke in https://bugs.launchpad.net/maria/+bug/1008293 , or if we're frank to ourselves, and admit that changing such things is hard (and does not bring much benefit) we make it static, fixed at the server startup,

5 older comments

Hide

Permalink

Peter (Stig) Edwards added a comment - 2013-07-15 12:11 - edited

Just had a crash on a 5.3.11 instance (mariadb-5.3.11-Linux-x86_64.tar.gz) while using:

  FLUSH TABLES WITH READ LOCK ; SET GLOBAL key_cache_segments = 64 ; UNLOCK TABLES;

The stack trace and query differ, the query is a SELECT, I have included the explain plan and table definitions.

Thank you.

130715  3:20:58 [ERROR] mysqld got signal 8 ;
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.3.11-MariaDB-log
key_buffer_size=1258291200
read_buffer_size=2097152
max_used_connections=214
max_threads=801
thread_count=18
connection_count=18
It is possible that mysqld could use up to
key_buffer_size + (read_buffer_size + sort_buffer_size)*max_threads = 6980843 K  bytes of memory
Hope that's ok; if not, decrease some variables in the equation.

Thread pointer: 0x0x2aab42ad1840
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 = 0x426cf0f8 thread_stack 0x48000
./bin/mysqld(my_print_stacktrace+0x2e) [0x9cb88e]
./bin/mysqld(handle_fatal_signal+0x3f9) [0x751eb9]
/lib64/libpthread.so.0 [0x3d52a0eb70]
./bin/mysqld(simple_key_cache_read+0xfa) [0x9d21aa]
./bin/mysqld(_mi_fetch_keypage+0x48) [0x814e18]
./bin/mysqld(_mi_search+0x7c) [0x80d48c]
./bin/mysqld(mi_rkey+0x16d) [0x7fdbad]
./bin/mysqld(ha_myisam::index_read_idx_map(unsigned char*, unsigned int, unsigned char const*, unsigned long, ha_rkey_function)+0x5d) [0x7e74ad]
./bin/mysqld [0x6a05f2]
./bin/mysqld [0x6a0974]
./bin/mysqld [0x6b6e8b]
./bin/mysqld(JOIN::optimize()+0xc87) [0x6b8b07]
./bin/mysqld(mysql_select(THD*, Item***, TABLE_LIST*, unsigned int, List<Item>&, Item*, unsigned int, st_order*, st_order*, Item*, st_order*, unsigned long long, select_result*, st_select_lex_unit*, st_select_lex*)+0xd6) [0x6c0966]
./bin/mysqld(handle_select(THD*, st_lex*, select_result*, unsigned long)+0x16f) [0x6c13ff]
./bin/mysqld [0x635c3e]
./bin/mysqld(mysql_execute_command(THD*)+0x3a43) [0x63b843]
./bin/mysqld(mysql_parse(THD*, char*, unsigned int, char const**)+0x299) [0x63e629]
./bin/mysqld(dispatch_command(enum_server_command, THD*, char*, unsigned int)+0xd56) [0x63f7d6]
./bin/mysqld(do_command(THD*)+0x101) [0x640081]
./bin/mysqld(handle_one_connection+0xfd) [0x6317fd]
/lib64/libpthread.so.0 [0x3d52a0673d]
/lib64/libc.so.6(clone+0x6d) [0x3d51ed44bd]

Trying to get some variables.
Some pointers may be invalid and cause the dump to abort.
Query (0x2aabbe867e38): /* comment */ SELECT f, pcds.b FROM mpcds pcds JOIN mcbm fcbm USING(bf_id) WHERE fcbm.f = 123456 LIMIT 5000
Connection ID (thread ID): 46182543
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,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

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.

+----+-------------+-------+-------+---------------+---------+---------+-------+------+-------+
| id | select_type | table | type  | possible_keys | key     | key_len | ref   | rows | Extra |
+----+-------------+-------+-------+---------------+---------+---------+-------+------+-------+
|  1 | SIMPLE      | fcbm  | const | PRIMARY       | PRIMARY | 4       | const |    1 |       |
|  1 | SIMPLE      | pcds  | const | PRIMARY       | PRIMARY | 10      | const |    1 |       |
+----+-------------+-------+-------+---------------+---------+---------+-------+------+-------+

CREATE TABLE `mpcds` (
  `bf_id` varchar(8) NOT NULL,
  `b` smallint(5) unsigned DEFAULT NULL,
  PRIMARY KEY (`bf_id`)
) ENGINE=MyISAM DEFAULT CHARSET=latin1 MAX_ROWS=999999999 PACK_KEYS=1

CREATE TABLE `mfcbm` (
  `f` int(10) unsigned NOT NULL,
  `c` char(9) DEFAULT NULL,
  `bf_id` varchar(8) DEFAULT NULL,
  PRIMARY KEY (`f`),
  KEY `compuid` (`c`,`f`)
) ENGINE=MyISAM DEFAULT CHARSET=latin1 MAX_ROWS=999999999 PACK_KEYS=1

Show

Peter (Stig) Edwards added a comment - 2013-07-15 12:11 - edited Just had a crash on a 5.3.11 instance (mariadb-5.3.11-Linux-x86_64.tar.gz) while using: FLUSH TABLES WITH READ LOCK ; SET GLOBAL key_cache_segments = 64 ; UNLOCK TABLES; The stack trace and query differ, the query is a SELECT, I have included the explain plan and table definitions. Thank you. 130715 3:20:58 [ERROR] mysqld got signal 8 ; 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.3.11-MariaDB-log key_buffer_size=1258291200 read_buffer_size=2097152 max_used_connections=214 max_threads=801 thread_count=18 connection_count=18 It is possible that mysqld could use up to key_buffer_size + (read_buffer_size + sort_buffer_size)*max_threads = 6980843 K bytes of memory Hope that's ok; if not, decrease some variables in the equation. Thread pointer: 0x0x2aab42ad1840 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 = 0x426cf0f8 thread_stack 0x48000 ./bin/mysqld(my_print_stacktrace+0x2e) [0x9cb88e] ./bin/mysqld(handle_fatal_signal+0x3f9) [0x751eb9] /lib64/libpthread.so.0 [0x3d52a0eb70] ./bin/mysqld(simple_key_cache_read+0xfa) [0x9d21aa] ./bin/mysqld(_mi_fetch_keypage+0x48) [0x814e18] ./bin/mysqld(_mi_search+0x7c) [0x80d48c] ./bin/mysqld(mi_rkey+0x16d) [0x7fdbad] ./bin/mysqld(ha_myisam::index_read_idx_map(unsigned char*, unsigned int, unsigned char const*, unsigned long, ha_rkey_function)+0x5d) [0x7e74ad] ./bin/mysqld [0x6a05f2] ./bin/mysqld [0x6a0974] ./bin/mysqld [0x6b6e8b] ./bin/mysqld(JOIN::optimize()+0xc87) [0x6b8b07] ./bin/mysqld(mysql_select(THD*, Item***, TABLE_LIST*, unsigned int, List<Item>&, Item*, unsigned int, st_order*, st_order*, Item*, st_order*, unsigned long long, select_result*, st_select_lex_unit*, st_select_lex*)+0xd6) [0x6c0966] ./bin/mysqld(handle_select(THD*, st_lex*, select_result*, unsigned long)+0x16f) [0x6c13ff] ./bin/mysqld [0x635c3e] ./bin/mysqld(mysql_execute_command(THD*)+0x3a43) [0x63b843] ./bin/mysqld(mysql_parse(THD*, char*, unsigned int, char const**)+0x299) [0x63e629] ./bin/mysqld(dispatch_command(enum_server_command, THD*, char*, unsigned int)+0xd56) [0x63f7d6] ./bin/mysqld(do_command(THD*)+0x101) [0x640081] ./bin/mysqld(handle_one_connection+0xfd) [0x6317fd] /lib64/libpthread.so.0 [0x3d52a0673d] /lib64/libc.so.6(clone+0x6d) [0x3d51ed44bd] Trying to get some variables. Some pointers may be invalid and cause the dump to abort. Query (0x2aabbe867e38): /* comment */ SELECT f, pcds.b FROM mpcds pcds JOIN mcbm fcbm USING(bf_id) WHERE fcbm.f = 123456 LIMIT 5000 Connection ID (thread ID): 46182543 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,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 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. +----+-------------+-------+-------+---------------+---------+---------+-------+------+-------+ | id | select_type | table | type | possible_keys | key | key_len | ref | rows | Extra | +----+-------------+-------+-------+---------------+---------+---------+-------+------+-------+ | 1 | SIMPLE | fcbm | const | PRIMARY | PRIMARY | 4 | const | 1 | | | 1 | SIMPLE | pcds | const | PRIMARY | PRIMARY | 10 | const | 1 | | +----+-------------+-------+-------+---------------+---------+---------+-------+------+-------+ CREATE TABLE `mpcds` ( `bf_id` varchar(8) NOT NULL, `b` smallint(5) unsigned DEFAULT NULL, PRIMARY KEY (`bf_id`) ) ENGINE=MyISAM DEFAULT CHARSET=latin1 MAX_ROWS=999999999 PACK_KEYS=1 CREATE TABLE `mfcbm` ( `f` int(10) unsigned NOT NULL, `c` char(9) DEFAULT NULL, `bf_id` varchar(8) DEFAULT NULL, PRIMARY KEY (`f`), KEY `compuid` (`c`,`f`) ) ENGINE=MyISAM DEFAULT CHARSET=latin1 MAX_ROWS=999999999 PACK_KEYS=1

Hide

Permalink

Peter (Stig) Edwards added a comment - 2013-07-22 19:32 - edited

Just wanted to note that if the reproducer is changed to use a pseudo-random values between 0 and 64 for key_cache_segments and 64M key_buffer_size it seems to crash more readily.

query_init:
  SET GLOBAL key_buffer_size = 64*1024*1024;
thread1:
  SET GLOBAL key_cache_segments = { $prng->int(0,64) } ;

query:
  REPLACE INTO E(col_int_key, col_datetime_key) VALUES(1, NOW());

Show

Peter (Stig) Edwards added a comment - 2013-07-22 19:32 - edited Just wanted to note that if the reproducer is changed to use a pseudo-random values between 0 and 64 for key_cache_segments and 64M key_buffer_size it seems to crash more readily. query_init: SET GLOBAL key_buffer_size = 64*1024*1024; thread1: SET GLOBAL key_cache_segments = { $prng->int(0,64) } ; query: REPLACE INTO E(col_int_key, col_datetime_key) VALUES(1, NOW());

Hide

Permalink

Sergei Golubchik added a comment - 2014-01-26 16:47

I couldn't repeat the crash. Neither in 5.5, nor in 5.3, with two of your grammars from above.

Show

Sergei Golubchik added a comment - 2014-01-26 16:47 I couldn't repeat the crash. Neither in 5.5, nor in 5.3, with two of your grammars from above.

Hide

Permalink

Elena Stepanova added a comment - 2014-02-27 19:15 - edited

I can easily reproduce it on 5.3, but not on 5.5 or 10.0.

From the history of the bug, it seems it had never been confirmed or seen by anyone on either 5.5 or 10.0; probably those versions crept into the 'Affected' list by some bulk update or something.
(I can't remove the versions from the list, as they appear as "archived", maybe you can).

So, I have set it up for 5.3 on perro in case you want to see it; but my vote is for not touching it in 5.3, at least unless/until somebody observes it on 5.5 or 10.0.

Show

Elena Stepanova added a comment - 2014-02-27 19:15 - edited I can easily reproduce it on 5.3, but not on 5.5 or 10.0. From the history of the bug, it seems it had never been confirmed or seen by anyone on either 5.5 or 10.0; probably those versions crept into the 'Affected' list by some bulk update or something. (I can't remove the versions from the list, as they appear as "archived", maybe you can). So, I have set it up for 5.3 on perro in case you want to see it; but my vote is for not touching it in 5.3, at least unless/until somebody observes it on 5.5 or 10.0.

Hide

Permalink

Elena Stepanova added a comment - 2015-06-02 02:44

Apparently it's not reproducible on 5.5 because during the test an attempt to set key_buffer_size causes the error:

MariaDB [(none)]> set global key_buffer_size = 64*1024*1024;
ERROR 1210 (HY000): Incorrect arguments to SET

I assume it's some kind of protection, although a bit ugly.

Current 5.3 still fails (only now for me it hangs, but it's all the same). However, it's certainly not the kind of a bug worth fixing in 5.3 now. So, I'm closing it as "won't fix"

Show

Elena Stepanova added a comment - 2015-06-02 02:44 Apparently it's not reproducible on 5.5 because during the test an attempt to set key_buffer_size causes the error: MariaDB [(none)]> set global key_buffer_size = 64*1024*1024; ERROR 1210 (HY000): Incorrect arguments to SET I assume it's some kind of protection, although a bit ugly. Current 5.3 still fails (only now for me it hangs, but it's all the same). However, it's certainly not the kind of a bug worth fixing in 5.3 now. So, I'm closing it as "won't fix"

Crash while running SET GLOBAL key_cache_segments = 64

Details

Description

Gliffy Diagrams

Attachments

Issue Links

Activity

People

Dates

Agile