rcannao,

Are you sure this backtrace is of the crashed thread? I don't see the signal handler there. Could you please attach all threads' stack trace?

Please also paste and attach your cnf file(s) and specify which build you were using.

Thanks.

Rene, Chris, Did you pinpoint a workload and setup that reproduced this error?

I upgraded a test server from 10.0.21 to 10.1.11 and ran a large amount of inserts and selects against it, with no issues. I also set up replication between 10.0.21 and 10.1.11 and ran concurrent inserts and selects, with no issues. This is on Centos7.

My tests were a very simple workload, though. I would like to continue to try to reproduce the error. What are the 10.0 and 10.1 versions you're using? OS and configs?

I don't have a scientific reproducible test case for this, but I can share some interesting patterns I found.
a) if the server that crashes because of this bug is a slave, when started InnoDB will perform a crash recovery without crashing again. But as soon as replication is resumed, the server will crash immediately
b) if the server that crashes because of this bug is a master, when started InnoDB will perform a crash recovery without crashing again. The server can receive again writes without crashing (go to point #c for exceptions)

Based on #a and #b , it seems that what caused the crash is not present anymore after a crash recovery. But #a points that maybe a specific write (that is stored in the relay log) causes the server to crash again.

c) the master crashes when executing large transactions involving updating several hundreds of thousands of rows and deleting a similar amount
d) reducing the size of the transactions to tens of thousands of rows (instead of hundreds of thousands of rows) won't crash the server

I want to highlight again that I don't have a reproducible test case to share (no core dump, no specific queries), but #c and #d were quite common patterns.

As the crashes seem somehow related to the size of the transactions, my hypothesis is:
Is it possible that the crash is caused by FIL_PAGE_FLUSH_LSN being written to undo pages, and incorrectly interpreted as an encryption key during read?
According to https://dev.mysql.com/worklog/task/?id=7990 , FIL_PAGE_FLUSH_LSN "was also being written to InnoDB undo tablespace files, even though the fields are not going to be consulted on crash recovery." (and in fact, no crash during crash recovery).

Similar to René, I don't have a reproducible test case for this either.

I did find out some extra details, which will hopefully help to isolate this.

1. This occurred after an in-place upgrade from MariaDB 10.0 to MariaDB 10.1.10

2. There had been a global tablespace error that also existed in the MariaDB 10.0 instance (but didn't cause problems in 10.0, so it went unnoticed). But when this tablespace error was encountered in 10.1.10 by mysqldump (note a mysqldump was in progress at the time of the crash), it triggered the crash. Unfortunately, I don't have further specifics regarding the exact tablespace error.

3. Here is the error log snippet of the crash & backtrace:

2016-02-25 19:42:46 140508033857280 [Warning] View 'test'.'vuser': there is unknown charset/collation names (client: ''; connection: '').
2016-02-25 19:42:46 140508033857280 [Warning] View 'test'.'vuser': there is unknown charset/collation names (client: ''; connection: '').
2016-02-25 19:42:46 140508033857280 [Warning] View 'test'.'vuser': there is unknown charset/collation names (client: ''; connection: '').
2016-02-25 19:43:40 140508084012800 [Warning] View 'test'.'vuser': there is unknown charset/collation names (client: ''; connection: '').
2016-02-25 19:43:40 140508084012800 [Warning] View 'test'.'vuser': there is unknown charset/collation names (client: ''; connection: '').
2016-02-25 19:43:40 140508084012800 [Warning] View 'test'.'vuser': there is unknown charset/collation names (client: ''; connection: '').
160225 19:51:53 [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.1.10-MariaDB-enterprise-log
key_buffer_size=268435456
read_buffer_size=131072
max_used_connections=10
max_threads=502
thread_count=1
It is possible that mysqld could use up to
key_buffer_size + (read_buffer_size + sort_buffer_size)*max_threads = 1364731 K bytes of memory
Hope that's ok; if not, decrease some variables in the equation.

Thread pointer: 0x0x7fca36f5d008
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 = 0x7fca966f7e00 thread_stack 0x48000
mysys/stacktrace.c:247(my_print_stacktrace)[0x7fca9723ae4b]
sql/signal_handler.cc:160(handle_fatal_signal)[0x7fca96d9bea5]
/lib64/libpthread.so.0(+0xf850)[0x7fca963b4850]
sql/encryption.cc:108(scheme_get_key)[0x7fca96d4fb33]
sql/encryption.cc:215(encryption_scheme_decrypt)[0x7fca96d4fdab]
fil/fil0crypt.cc:753(fil_space_decrypt(fil_space_crypt_struct*, unsigned char*, unsigned long, unsigned char*, dberr_t*))[0x7fca971ba134]
fil/fil0crypt.cc:810(fil_space_decrypt(unsigned long, unsigned char*, unsigned long, unsigned char*))[0x7fca971ba2ae]
buf/buf0buf.cc:6397(buf_page_decrypt_after_read(buf_page_t*))[0x7fca971586c3]
buf/buf0buf.cc:4630(buf_page_io_complete(buf_page_t*))[0x7fca97158a80]
buf/buf0rea.cc:262(buf_read_page_low(dberr_t*, bool, unsigned long, unsigned long, unsigned long, unsigned long, long, unsigned long, trx_t*, buf_page_t**))[0x7fca97170fd8]
buf/buf0rea.cc:474(buf_read_page(unsigned long, unsigned long, unsigned long, trx_t*, buf_page_t**))[0x7fca97171aef]
buf/buf0buf.cc:2942(buf_page_get_gen(unsigned long, unsigned long, unsigned long, unsigned long, buf_block_t*, unsigned long, char const*, unsigned long, mtr_t*, dberr_t*))[0x7fca97150ddf]
include/btr0btr.ic:62(btr_block_get_func)[0x7fca9713b154]
include/btr0pcur.ic:368(btr_pcur_move_to_next)[0x7fca970c98a8]
row/row0sel.cc:5129(row_search_for_mysql(unsigned char*, unsigned long, row_prebuilt_t*, unsigned long, unsigned long))[0x7fca970cd51e]
handler/ha_innodb.cc:9914(ha_innobase::general_fetch(unsigned char*, unsigned int, unsigned int))[0x7fca9700be0f]
sql/handler.cc:2577(handler::ha_rnd_next(unsigned char*))[0x7fca96da066f]
sql/records.cc:470(rr_sequential(READ_RECORD*))[0x7fca96e92480]
sql/sql_select.cc:18302(sub_select(JOIN*, st_join_table*, bool))[0x7fca96c613e2]
sql/sql_select.cc:17937(do_select)[0x7fca96c6de2d]
sql/sql_select.cc:3228(JOIN::exec_inner())[0x7fca96c7e9b0]
sql/sql_select.cc:2519(JOIN::exec())[0x7fca96c8092d]
sql/sql_select.cc:3453(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*))[0x7fca96c7d2ea]
sql/sql_select.cc:384(handle_select(THD*, LEX*, select_result*, unsigned long))[0x7fca96c80c0d]
sql/sql_parse.cc:5903(execute_sqlcom_select)[0x7fca96c23b52]
sql/sql_parse.cc:2961(mysql_execute_command(THD*))[0x7fca96c2fdc3]
sql/sql_parse.cc:7302(mysql_parse)[0x7fca96c3313d]
sql/sql_parse.cc:1487(dispatch_command(enum_server_command, THD*, char*, unsigned int))[0x7fca96c35bf3]
sql/sql_parse.cc:1111(do_command(THD*))[0x7fca96c3618b]
sql/sql_connect.cc:1349(do_handle_one_connection(THD*))[0x7fca96cf150f]
sql/sql_connect.cc:1263(handle_one_connection)[0x7fca96cf1667]
/lib64/libpthread.so.0(+0x7806)[0x7fca963ac806]
/lib64/libc.so.6(clone+0x6d)[0x7fca94b3264d]

Trying to get some variables.
Some pointers may be invalid and cause the dump to abort.
Query (0x7fca48ff2020): is an invalid pointer
Connection ID (thread ID): 3927
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

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.
160225 19:51:54 mysqld_safe Number of processes running now: 0
160225 19:51:54 mysqld_safe mysqld restarted

rcannao,

Did you also have any kind of a global tablespace error before or upon the upgrade, similar to what ccalender mentioned in the previous comment? I suppose if you had it, it would show in the error log, could you maybe check it for errors?
Also, when you are saying

The master crashes when executing large transactions involving updating several hundreds of thousands of rows and deleting a similar amount

is it about concurrent updates/deletes, or sequential actions on the same table? Is it limited to the same table(s)? If so, can you paste SHOW CREATE and SHOW INDEX? Do you remember whether these tables were created in 10.0 or in previous versions?

Thanks.

commit f341d94423daa37bf4bee4d9b96ba8e8d93484c6
Author: Jan Lindström <jan.lindstrom@mariadb.com>
Date: Sat Mar 12 13:43:33 2016 +0200

MDEV-9549: Trying to decrypt a not encrypted page

Make sure that on decrypt we do not try to reference
NULL pointer and if page contains undefined
FIL_PAGE_FILE_FLUSH_LSN field on when page is not
the first page or page is not in system tablespace,
clear it.