[MDEV-8173] InnoDB; Failing assertion: crypt_data->type == 1 - Jira

Details

Type: Bug
Status: Closed (View Workflow)
Priority: Major
Resolution: Won't Fix
Affects Version/s: 10.1.4
Fix Version/s: N/A
Component/s: Encryption, Storage Engine - InnoDB, Storage Engine - XtraDB
Labels:
- verified

Description

Let below test crash at least once, after that crash recovery will fail always to this same asertion.

# 2015-05-18T15:12:27 [8106] | 2015-05-18 15:08:27 7f9b20234780  InnoDB: Assertion failure in thread 140304235841408 in file fil0crypt.cc line 771

# 2015-05-18T15:12:27 [8106] | InnoDB: Failing assertion: crypt_data->type == 1

# 2015-05-18T15:12:27 [8106] | InnoDB: We intentionally generate a memory trap.

# 2015-05-18T15:12:27 [8106] | InnoDB: Submit a detailed bug report to http://bugs.mysql.com.

# 2015-05-18T15:12:27 [8106] | InnoDB: If you get repeated assertion failures or crashes, even

# 2015-05-18T15:12:27 [8106] | InnoDB: immediately after the mysqld startup, there may be

# 2015-05-18T15:12:27 [8106] | InnoDB: corruption in the InnoDB tablespace. Please refer to

# 2015-05-18T15:12:27 [8106] | InnoDB: http://dev.mysql.com/doc/refman/5.6/en/forcing-innodb-recovery.html

# 2015-05-18T15:12:27 [8106] | InnoDB: about forcing recovery.

# 2015-05-18T15:12:27 [8106] | 150518 15:08:27 [ERROR] mysqld got signal 6 ;

# 2015-05-18T15:12:27 [8106] | This could be because you hit a bug. It is also possible that this binary

# 2015-05-18T15:12:27 [8106] | or one of the libraries it was linked against is corrupt, improperly built,

# 2015-05-18T15:12:27 [8106] | or misconfigured. This error can also be caused by malfunctioning hardware.

# 2015-05-18T15:12:27 [8106] |

# 2015-05-18T15:12:27 [8106] | To report this bug, see http://kb.askmonty.org/en/reporting-bugs

# 2015-05-18T15:12:27 [8106] |

# 2015-05-18T15:12:27 [8106] | We will try our best to scrape up some info that will hopefully help

# 2015-05-18T15:12:27 [8106] | diagnose the problem, but since we have already crashed,

# 2015-05-18T15:12:27 [8106] | something is definitely wrong and this may fail.

# 2015-05-18T15:12:27 [8106] |

# 2015-05-18T15:12:27 [8106] | Server version: 10.1.5-MariaDB-wsrep-debug-log

# 2015-05-18T15:12:27 [8106] | key_buffer_size=134217728

# 2015-05-18T15:12:27 [8106] | read_buffer_size=131072

# 2015-05-18T15:12:27 [8106] | max_used_connections=0

# 2015-05-18T15:12:27 [8106] | max_threads=153

# 2015-05-18T15:12:28 [8106] | thread_count=0

# 2015-05-18T15:12:28 [8106] | It is possible that mysqld could use up to

# 2015-05-18T15:12:28 [8106] | key_buffer_size + (read_buffer_size + sort_buffer_size)*max_threads = 467322 K  bytes of memory

# 2015-05-18T15:12:28 [8106] | Hope that's ok; if not, decrease some variables in the equation.

# 2015-05-18T15:12:28 [8106] |

# 2015-05-18T15:12:28 [8106] | Thread pointer: 0x0x0

# 2015-05-18T15:12:28 [8106] | Attempting backtrace. You can use the following information to find out

# 2015-05-18T15:12:28 [8106] | where mysqld died. If you see no messages after this, something went

# 2015-05-18T15:12:28 [8106] | terribly wrong...

# 2015-05-18T15:12:28 [8106] | stack_bottom = 0x0 thread_stack 0x48000

# 2015-05-18T15:12:28 [8106] | mysys/stacktrace.c:246(my_print_stacktrace)[0x7f9b20f9301c]

# 2015-05-18T15:12:28 [8106] | sql/signal_handler.cc:155(handle_fatal_signal)[0x7f9b20940075]

# 2015-05-18T15:12:28 [8106] | /lib/x86_64-linux-gnu/libpthread.so.0(+0x10340)[0x7f9b1e759340]

# 2015-05-18T15:12:28 [8106] | /lib/x86_64-linux-gnu/libc.so.6(gsignal+0x39)[0x7f9b1ddb0cc9]

# 2015-05-18T15:12:28 [8106] | /lib/x86_64-linux-gnu/libc.so.6(abort+0x148)[0x7f9b1ddb40d8]

# 2015-05-18T15:12:28 [8106] | fil/fil0crypt.cc:775(fil_space_decrypt(fil_space_crypt_struct*, unsigned char const*, unsigned long, unsigned char*))[0x7f9b20eeb5dc]

# 2015-05-18T15:12:28 [8106] | fil/fil0crypt.cc:846(fil_space_decrypt(unsigned long, unsigned char const*, unsigned long, unsigned char*))[0x7f9b20eeb7f0]

# 2015-05-18T15:12:28 [8106] | buf/buf0buf.cc:6038(buf_page_decrypt_after_read(buf_page_t*))[0x7f9b20e745ce]

# 2015-05-18T15:12:28 [8106] | buf/buf0buf.cc:4323(buf_page_io_complete(buf_page_t*))[0x7f9b20e70b0e]

# 2015-05-18T15:12:28 [8106] | buf/buf0rea.cc:261(buf_read_page_low(dberr_t*, bool, unsigned long, unsigned long, unsigned long, unsigned long, long, unsigned long, trx_t*))[0x7f9b20e8e953]

# 2015-05-18T15:12:28 [8106] | buf/buf0rea.cc:465(buf_read_page(unsigned long, unsigned long, unsigned long, trx_t*))[0x7f9b20e8ed95]

# 2015-05-18T15:12:28 [8106] | buf/buf0buf.cc:2789(buf_page_get_gen(unsigned long, unsigned long, unsigned long, unsigned long, buf_block_t*, unsigned long, char const*, unsigned long, mtr_t*))[0x7f9b20e6d1bc]

# 2015-05-18T15:12:28 [8106] | dict/dict0boot.cc:56(dict_hdr_get(mtr_t*))[0x7f9b20e95e7c]

# 2015-05-18T15:12:28 [8106] | dict/dict0boot.cc:286(dict_boot())[0x7f9b20e964d2]

# 2015-05-18T15:12:28 [8106] | srv/srv0start.cc:2543(innobase_start_or_create_for_mysql())[0x7f9b20dddd5d]

# 2015-05-18T15:12:28 [8106] | handler/ha_innodb.cc:4107(innobase_init)[0x7f9b20c76dd9]

# 2015-05-18T15:12:28 [8106] | sql/handler.cc:512(ha_initialize_handlerton(st_plugin_int*))[0x7f9b20941fde]

# 2015-05-18T15:12:28 [8106] | sql/sql_plugin.cc:1403(plugin_initialize)[0x7f9b2072ca24]

# 2015-05-18T15:12:28 [8106] | sql/sql_plugin.cc:1675(plugin_init(int*, char**, int))[0x7f9b2072d5e7]

# 2015-05-18T15:12:28 [8106] | sql/mysqld.cc:5039(init_server_components)[0x7f9b2064fa1e]

# 2015-05-18T15:12:28 [8106] | sql/mysqld.cc:5631(mysqld_main(int, char**))[0x7f9b20650b52]

# 2015-05-18T15:12:28 [8106] | sql/main.cc:26(main)[0x7f9b20646895]

# 2015-05-18T15:12:28 [8106] | /lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xf5)[0x7f9b1dd9bec5]

# 2015-05-18T15:12:28 [8106] | /home/jan/mysql/10.1-encryption/sql/mysqld(+0x3d5788)[0x7f9b20646788]

# 2015-05-18T15:12:28 [8106] | The manual page at http://dev.mysql.com/doc/mysql/en/crashing.html contains

# 2015-05-18T15:12:28 [8106] | information that should help you find out what is causing the crash.

# 2015-05-18T15:12:28 [8106] | Writing a core file

# 2015-05-18T15:12:28 [8106] | Aborted (core dumped)

query:

        INSERT IGNORE INTO _table ( _field ) VALUES ( _digit ), ( _digit ), ( _digit ), ( _digit ) |

        DELETE FROM _table WHERE `pk` > _digit LIMIT 4 ;

thread2:

        set_encrypt_option |

        create_or_replace;

set_encrypt_option:

        SET GLOBAL innodb_encrypt_tables = enc_tables |

        SET GLOBAL innodb_encryption_threads = _digit |

        SET GLOBAL innodb_scrub_log_speed = _smallint_unsigned

encrypt_on_off:

        ON | OFF ;

enc_tables:

        ON | OFF | 'FORCE' ;

create_or_replace:

        CREATE OR REPLACE TABLE `create_or_replace_t` AS SELECT * FROM _table ;

RQG data template enc2.zz
$tables = {
rows => [0, 1, 10 ],
pk => [ 'int auto_increment' ]
};

$fields = {
types => [ 'int' ],
indexes => [ 'key', undef ]
};

$data = {
numbers => [ 'digit', 'null', undef ],
strings => [ 'letter', 'english' ],
blobs => [ 'data' ],
temporals => ['date', 'year', 'null', undef ]
}

RQG command line (use lp:~elenst/randgen/mariadb-patches):

perl ./runall-new.pl --threads=2 --duration=400 --queries=100M --mysqld=--plugin-load-add=file_key_management.so --mysqld=--file_key_management_filename=<your basedir>/mysql-test/std_data/keys.txt --grammar=enc2.yy --gendata=enc2.zz --mtr-build-thread=73 --basedir1=<your basedir> --vardir1=<your vardir>

See ~~MDEV-8171~~ for instructions how to run the same test several times.

Attachments

Issue Links

blocks

MDEV-8172 Intermittent InnoDB: Failing assertion: crypt_data and InnoDB: Failing assertion: mutex->magic_n == MUTEX_MAGIC_N

Closed

Activity

Ascending order - Click to sort in descending order

Jan Lindström (Inactive) created issue - 2015-05-18 15:14

Jan Lindström (Inactive) made changes - 2015-05-18 15:15

Field	Original Value	New Value
Description	_Note: reproducible on the current 10.1 tree commit 476dfb1603 plus the patch for ~~MDEV-8164~~ applied locally (either 6f1114b or eefada5, all the same). The stack traces below are from the latter patch on top of 10.1 tree._ The two failures below happen intermittently on the same test, which is why I am filing them together. I don't know if they have the same root cause or not. {noformat} 2015-05-17 21:13:51 7f182cbfc700 InnoDB: Assertion failure in thread 139741806708480 in file fil0crypt.cc line 1577 InnoDB: Failing assertion: crypt_data InnoDB: We intentionally generate a memory trap. # 2015-05-17T21:13:57 [58831] #5 0x00007f185b8bdb8b in abort () from /lib/x86_64-linux-gnu/libc.so.6 # 2015-05-17T21:13:57 [58831] #6 0x00007f185e59de07 in fil_crypt_find_page_to_rotate (key_state=0x7f182cbfbd90, state=0x7f182cbfbda0) at /home/elenst/git/10.1/storage/xtradb/fil/fil0crypt.cc:1577 # 2015-05-17T21:13:57 [58831] #7 0x00007f185e59f073 in fil_crypt_thread (arg=0x0) at /home/elenst/git/10.1/storage/xtradb/fil/fil0crypt.cc:2156 # 2015-05-17T21:13:57 [58831] #8 0x00007f185c24ae9a in start_thread () from /lib/x86_64-linux-gnu/libpthread.so.0 # 2015-05-17T21:13:57 [58831] #9 0x00007f185b977cbd in clone () from /lib/x86_64-linux-gnu/libc.so.6 {noformat} {noformat} 2015-05-17 21:17:52 7f0e30ffc700 InnoDB: Assertion failure in thread 139698928338688 in file sync0sync.cc line 485 InnoDB: Failing assertion: mutex->magic_n == MUTEX_MAGIC_N InnoDB: We intentionally generate a memory trap. # 2015-05-17T21:17:58 [59088] #5 0x00007f0e5fdbeb8b in abort () from /lib/x86_64-linux-gnu/libc.so.6 # 2015-05-17T21:17:58 [59088] #6 0x00007f0e62998aa8 in mutex_validate (mutex=0x7f0e3280e7f8) at /home/elenst/git/10.1/storage/xtradb/ sync/sync0sync.cc:485 # 2015-05-17T21:17:58 [59088] #7 0x00007f0e62a9b551 in mutex_enter_func (mutex=0x7f0e3280e7f8, file_name=0x7f0e62ddd8e0 "/home/elenst /git/10.1/storage/xtradb/fil/fil0crypt.cc", line=2077) at /home/elenst/git/10.1/storage/xtradb/include/sync0sync.ic:257 # 2015-05-17T21:17:58 [59088] #8 0x00007f0e62a9b6a3 in pfs_mutex_enter_func (mutex=0x7f0e3280e7f8, file_name=0x7f0e62ddd8e0 "/home/el enst/git/10.1/storage/xtradb/fil/fil0crypt.cc", line=2077) at /home/elenst/git/10.1/storage/xtradb/include/sync0sync.ic:379 # 2015-05-17T21:17:58 [59088] #9 0x00007f0e62a9fe94 in fil_crypt_complete_rotate_space (key_state=0x7f0e30ffbd90, state=0x7f0e30ffbda 0) at /home/elenst/git/10.1/storage/xtradb/fil/fil0crypt.cc:2077 # 2015-05-17T21:17:58 [59088] #10 0x00007f0e62aa00a0 in fil_crypt_thread (arg=0x0) at /home/elenst/git/10.1/storage/xtradb/fil/fil0crypt.cc:2166 # 2015-05-17T21:17:58 [59088] #11 0x00007f0e6074be9a in start_thread () from /lib/x86_64-linux-gnu/libpthread.so.0 # 2015-05-17T21:17:58 [59088] #12 0x00007f0e5fe78cbd in clone () from /lib/x86_64-linux-gnu/libc.so.6 {noformat} Results of 10 subsequent runs of the test below: - 2 times it passed - 3 times it ended with Failing assertion: crypt_data - 5 times it ended with Failing assertion: mutex->magic_n == MUTEX_MAGIC_N {noformat:RQG grammar enc2.yy} query: INSERT IGNORE INTO _table ( _field ) VALUES ( _digit ), ( _digit ), ( _digit ), ( _digit ) \| DELETE FROM _table WHERE `pk` > _digit LIMIT 4 ; thread2: set_encrypt_option \| create_or_replace; set_encrypt_option: SET GLOBAL innodb_encrypt_tables = enc_tables \| SET GLOBAL innodb_encryption_threads = _digit \| SET GLOBAL innodb_scrub_log_speed = _smallint_unsigned ; encrypt_on_off: ON \| OFF ; enc_tables: ON \| OFF \| 'FORCE' ; create_or_replace: CREATE OR REPLACE TABLE `create_or_replace_t` AS SELECT * FROM _table ; {noformat} {noformat:title=RQG data template enc2.zz} $tables = { rows => [0, 1, 10 ], pk => [ 'int auto_increment' ] }; $fields = { types => [ 'int' ], indexes => [ 'key', undef ] }; $data = { numbers => [ 'digit', 'null', undef ], strings => [ 'letter', 'english' ], blobs => [ 'data' ], temporals => ['date', 'year', 'null', undef ] } {noformat} RQG command line (use lp:~elenst/randgen/mariadb-patches): {noformat} perl ./runall-new.pl --threads=2 --duration=400 --queries=100M --mysqld=--plugin-load-add=file_key_management.so --mysqld=--file_key_management_filename=<your basedir>/mysql-test/std_data/keys.txt --grammar=enc2.yy --gendata=enc2.zz --mtr-build-thread=73 --basedir1=<your basedir> --vardir1=<your vardir> {noformat} See ~~MDEV-8171~~ for instructions how to run the same test several times.	Let below test crash at least once, after that crash recovery will fail always to this same asertion. {noformat} # 2015-05-18T15:12:27 [8106] \| 2015-05-18 15:08:27 7f9b20234780 InnoDB: Assertion failure in thread 140304235841408 in file fil0crypt.cc line 771 # 2015-05-18T15:12:27 [8106] \| InnoDB: Failing assertion: crypt_data->type == 1 # 2015-05-18T15:12:27 [8106] \| InnoDB: We intentionally generate a memory trap. # 2015-05-18T15:12:27 [8106] \| InnoDB: Submit a detailed bug report to http://bugs.mysql.com. # 2015-05-18T15:12:27 [8106] \| InnoDB: If you get repeated assertion failures or crashes, even # 2015-05-18T15:12:27 [8106] \| InnoDB: immediately after the mysqld startup, there may be # 2015-05-18T15:12:27 [8106] \| InnoDB: corruption in the InnoDB tablespace. Please refer to # 2015-05-18T15:12:27 [8106] \| InnoDB: http://dev.mysql.com/doc/refman/5.6/en/forcing-innodb-recovery.html # 2015-05-18T15:12:27 [8106] \| InnoDB: about forcing recovery. # 2015-05-18T15:12:27 [8106] \| 150518 15:08:27 [ERROR] mysqld got signal 6 ; # 2015-05-18T15:12:27 [8106] \| This could be because you hit a bug. It is also possible that this binary # 2015-05-18T15:12:27 [8106] \| or one of the libraries it was linked against is corrupt, improperly built, # 2015-05-18T15:12:27 [8106] \| or misconfigured. This error can also be caused by malfunctioning hardware. # 2015-05-18T15:12:27 [8106] \| # 2015-05-18T15:12:27 [8106] \| To report this bug, see http://kb.askmonty.org/en/reporting-bugs # 2015-05-18T15:12:27 [8106] \| # 2015-05-18T15:12:27 [8106] \| We will try our best to scrape up some info that will hopefully help # 2015-05-18T15:12:27 [8106] \| diagnose the problem, but since we have already crashed, # 2015-05-18T15:12:27 [8106] \| something is definitely wrong and this may fail. # 2015-05-18T15:12:27 [8106] \| # 2015-05-18T15:12:27 [8106] \| Server version: 10.1.5-MariaDB-wsrep-debug-log # 2015-05-18T15:12:27 [8106] \| key_buffer_size=134217728 # 2015-05-18T15:12:27 [8106] \| read_buffer_size=131072 # 2015-05-18T15:12:27 [8106] \| max_used_connections=0 # 2015-05-18T15:12:27 [8106] \| max_threads=153 # 2015-05-18T15:12:28 [8106] \| thread_count=0 # 2015-05-18T15:12:28 [8106] \| It is possible that mysqld could use up to # 2015-05-18T15:12:28 [8106] \| key_buffer_size + (read_buffer_size + sort_buffer_size)max_threads = 467322 K bytes of memory # 2015-05-18T15:12:28 [8106] \| Hope that's ok; if not, decrease some variables in the equation. # 2015-05-18T15:12:28 [8106] \| # 2015-05-18T15:12:28 [8106] \| Thread pointer: 0x0x0 # 2015-05-18T15:12:28 [8106] \| Attempting backtrace. You can use the following information to find out # 2015-05-18T15:12:28 [8106] \| where mysqld died. If you see no messages after this, something went # 2015-05-18T15:12:28 [8106] \| terribly wrong... # 2015-05-18T15:12:28 [8106] \| stack_bottom = 0x0 thread_stack 0x48000 # 2015-05-18T15:12:28 [8106] \| mysys/stacktrace.c:246(my_print_stacktrace)[0x7f9b20f9301c] # 2015-05-18T15:12:28 [8106] \| sql/signal_handler.cc:155(handle_fatal_signal)[0x7f9b20940075] # 2015-05-18T15:12:28 [8106] \| /lib/x86_64-linux-gnu/libpthread.so.0(+0x10340)[0x7f9b1e759340] # 2015-05-18T15:12:28 [8106] \| /lib/x86_64-linux-gnu/libc.so.6(gsignal+0x39)[0x7f9b1ddb0cc9] # 2015-05-18T15:12:28 [8106] \| /lib/x86_64-linux-gnu/libc.so.6(abort+0x148)[0x7f9b1ddb40d8] # 2015-05-18T15:12:28 [8106] \| fil/fil0crypt.cc:775(fil_space_decrypt(fil_space_crypt_struct, unsigned char const, unsigned long, unsigned char))[0x7f9b20eeb5dc] # 2015-05-18T15:12:28 [8106] \| fil/fil0crypt.cc:846(fil_space_decrypt(unsigned long, unsigned char const, unsigned long, unsigned char))[0x7f9b20eeb7f0] # 2015-05-18T15:12:28 [8106] \| buf/buf0buf.cc:6038(buf_page_decrypt_after_read(buf_page_t))[0x7f9b20e745ce] # 2015-05-18T15:12:28 [8106] \| buf/buf0buf.cc:4323(buf_page_io_complete(buf_page_t))[0x7f9b20e70b0e] # 2015-05-18T15:12:28 [8106] \| buf/buf0rea.cc:261(buf_read_page_low(dberr_t, bool, unsigned long, unsigned long, unsigned long, unsigned long, long, unsigned long, trx_t))[0x7f9b20e8e953] # 2015-05-18T15:12:28 [8106] \| buf/buf0rea.cc:465(buf_read_page(unsigned long, unsigned long, unsigned long, trx_t))[0x7f9b20e8ed95] # 2015-05-18T15:12:28 [8106] \| buf/buf0buf.cc:2789(buf_page_get_gen(unsigned long, unsigned long, unsigned long, unsigned long, buf_block_t, unsigned long, char const, unsigned long, mtr_t))[0x7f9b20e6d1bc] # 2015-05-18T15:12:28 [8106] \| dict/dict0boot.cc:56(dict_hdr_get(mtr_t))[0x7f9b20e95e7c] # 2015-05-18T15:12:28 [8106] \| dict/dict0boot.cc:286(dict_boot())[0x7f9b20e964d2] # 2015-05-18T15:12:28 [8106] \| srv/srv0start.cc:2543(innobase_start_or_create_for_mysql())[0x7f9b20dddd5d] # 2015-05-18T15:12:28 [8106] \| handler/ha_innodb.cc:4107(innobase_init)[0x7f9b20c76dd9] # 2015-05-18T15:12:28 [8106] \| sql/handler.cc:512(ha_initialize_handlerton(st_plugin_int))[0x7f9b20941fde] # 2015-05-18T15:12:28 [8106] \| sql/sql_plugin.cc:1403(plugin_initialize)[0x7f9b2072ca24] # 2015-05-18T15:12:28 [8106] \| sql/sql_plugin.cc:1675(plugin_init(int, char, int))[0x7f9b2072d5e7] # 2015-05-18T15:12:28 [8106] \| sql/mysqld.cc:5039(init_server_components)[0x7f9b2064fa1e] # 2015-05-18T15:12:28 [8106] \| sql/mysqld.cc:5631(mysqld_main(int, char))[0x7f9b20650b52] # 2015-05-18T15:12:28 [8106] \| sql/main.cc:26(main)[0x7f9b20646895] # 2015-05-18T15:12:28 [8106] \| /lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xf5)[0x7f9b1dd9bec5] # 2015-05-18T15:12:28 [8106] \| /home/jan/mysql/10.1-encryption/sql/mysqld(+0x3d5788)[0x7f9b20646788] # 2015-05-18T15:12:28 [8106] \| The manual page at http://dev.mysql.com/doc/mysql/en/crashing.html contains # 2015-05-18T15:12:28 [8106] \| information that should help you find out what is causing the crash. # 2015-05-18T15:12:28 [8106] \| Writing a core file # 2015-05-18T15:12:28 [8106] \| Aborted (core dumped) {noformat} {noformat:RQG grammar enc2.yy} query: INSERT IGNORE INTO _table ( _field ) VALUES ( _digit ), ( _digit ), ( _digit ), ( _digit ) \| DELETE FROM _table WHERE `pk` > _digit LIMIT 4 ; thread2: set_encrypt_option \| create_or_replace; set_encrypt_option: SET GLOBAL innodb_encrypt_tables = enc_tables \| SET GLOBAL innodb_encryption_threads = _digit \| SET GLOBAL innodb_scrub_log_speed = _smallint_unsigned ; encrypt_on_off: ON \| OFF ; enc_tables: ON \| OFF \| 'FORCE' ; create_or_replace: CREATE OR REPLACE TABLE `create_or_replace_t` AS SELECT FROM _table ; {noformat} {noformat:title=RQG data template enc2.zz} $tables = { rows => [0, 1, 10 ], pk => [ 'int auto_increment' ] }; $fields = { types => [ 'int' ], indexes => [ 'key', undef ] }; $data = { numbers => [ 'digit', 'null', undef ], strings => [ 'letter', 'english' ], blobs => [ 'data' ], temporals => ['date', 'year', 'null', undef ] } {noformat} RQG command line (use lp:~elenst/randgen/mariadb-patches): {noformat} perl ./runall-new.pl --threads=2 --duration=400 --queries=100M --mysqld=--plugin-load-add=file_key_management.so --mysqld=--file_key_management_filename=<your basedir>/mysql-test/std_data/keys.txt --grammar=enc2.yy --gendata=enc2.zz --mtr-build-thread=73 --basedir1=<your basedir> --vardir1=<your vardir> {noformat} See ~~MDEV-8171~~ for instructions how to run the same test several times.

Jan Lindström (Inactive) made changes - 2015-05-18 15:16

Affects Version/s		10.1.4 [ 18400 ]
Affects Version/s	10.1 [ 16100 ]

Jan Lindström (Inactive) made changes - 2015-05-18 15:17

Link

This issue blocks ~~MDEV-8172~~ [ ~~MDEV-8172~~ ]

Jan Lindström (Inactive) made changes - 2015-05-18 15:18

Status

Open [ 1 ]

In Progress [ 3 ]

Rasmus Johansson (Inactive) made changes - 2015-05-18 17:51

Workflow

MariaDB v2 [ 60988 ]

MariaDB v3 [ 67129 ]

Jan Lindström (Inactive) made changes - 2015-05-19 12:17

Summary

InnoDB; Failing assertion: crypt_data->type == 1 on crash recovery

InnoDB; Failing assertion: crypt_data->type == 1

Jan Lindström (Inactive) made changes - 2015-05-19 12:19

Labels

verified

Jan Lindström (Inactive) made changes - 2015-05-20 14:15

Assignee

Jan Lindström [ jplindst ]

Sergei Golubchik [ serg ]

Sergei Golubchik made changes - 2015-06-17 20:11

Status

In Progress [ 3 ]

Stalled [ 10000 ]

Sergei Golubchik made changes - 2019-08-05 09:15

Fix Version/s		N/A [ 14700 ]
Fix Version/s	10.1 [ 16100 ]
Resolution		Won't Fix [ 2 ]
Status	Stalled [ 10000 ]	Closed [ 6 ]

Sergei Golubchik made changes - 2021-12-06 21:41

Workflow

MariaDB v3 [ 67129 ]

MariaDB v4 [ 149181 ]

People

Assignee:: Sergei Golubchik

Reporter:: Jan Lindström (Inactive)

Votes:: 0 Vote for this issue

Watchers:: 4 Start watching this issue

Dates

Created:: 2015-05-18 15:14

Updated:: 2019-08-05 09:15

Resolved:: 2019-08-05 09:15

Git Integration

Error rendering 'com.xiplink.jira.git.jira_git_plugin:git-issue-webpanel'. Please contact your Jira administrators.

MariaDB Server