[MDEV-8015] InnoDB: Failing assertion: new_state->key_version != ENCRYPTION_KEY_VERSION_INVALID Created: 2015-04-18  Updated: 2015-05-13  Resolved: 2015-05-11

Status: Closed
Project: MariaDB Server
Component/s: Encryption, Storage Engine - InnoDB, Storage Engine - XtraDB
Affects Version/s: 10.1.4
Fix Version/s: 10.1.5

Type: Bug Priority: Major
Reporter: Elena Stepanova Assignee: Sergei Golubchik
Resolution: Fixed Votes: 0
Labels: verified

Issue Links:
Duplicate
duplicates MDEV-7855 InnoDB should refuse to start if inno... Closed
Relates
relates to MDEV-8158 InnoDB: Failing assertion: new_state-... Closed

 Description   

If the server starts on a fresh datadir with 

innodb-encrypt-tables
 
innodb-encryption-threads = 4

(only with them on top of defaults),
it goes down with the assertion failure:

Stack trace from 10.1 commit 22a7b4dee0

 
2015-04-18 04:08:34 7fe59fbfa700  InnoDB: Assertion failure in thread 140624204375808 in file fil0crypt.cc line 988
 
InnoDB: Failing assertion: new_state->key_version != ENCRYPTION_KEY_VERSION_INVALID
 
InnoDB: We intentionally generate a memory trap.
 
 
 
#0  0x00007fe5c8fe8165 in *__GI_raise (sig=<optimized out>) at ../nptl/sysdeps/unix/sysv/linux/raise.c:64
 
#1  0x00007fe5c8feb3e0 in *__GI_abort () at abort.c:92
 
#2  0x00007fe5cbf5c59c in fil_crypt_get_key_state (new_state=0x7fe59ebfed90) at 10.1/storage/xtradb/fil/fil0crypt.cc:988
 
#3  0x00007fe5cbf5e734 in fil_crypt_thread (arg=0x0) at 10.1/storage/xtradb/fil/fil0crypt.cc:2148
 
#4  0x00007fe5caffcb50 in start_thread (arg=<optimized out>) at pthread_create.c:304
 
#5  0x00007fe5c909195d in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:112
 
#6  0x0000000000000000 in ?? ()



 Comments   
Comment by Sergei Golubchik [ 2015-05-09 ]

This is not a bug, it's intentional. You've requested InnoDB to encrypt the data and didn't load an encryption plugin. InnoDB tries to get an encryption key, fails, and crashes the server (which is a typical InnoDB reaction to errors).

Despite being intentional, I agree that it's not good. I'll try to do something about it.

Comment by Elena Stepanova [ 2015-05-10 ]

I find it somewhat weird – I mean not technically, but logically – that it only fails with innodb-encryption-threads, but doesn't fail if I only set innodb-encrypt-tables.
But anyway, please at least make the assertion more comprehensive for a user, or somehow else print a clear error message in the log.

Comment by Sergei Golubchik [ 2015-05-10 ]

jplindst, could you please look at it?

I've fixed the assertion rather simply:

diff --git a/storage/xtradb/handler/ha_innodb.cc b/storage/xtradb/handler/ha_inn
 
--- a/storage/xtradb/handler/ha_innodb.cc
 
+++ b/storage/xtradb/handler/ha_innodb.cc
 
@@ -3633,6 +3633,14 @@ innobase_init(
 
        }
 
 #endif
 
 
+       if ((srv_encrypt_tables || srv_encrypt_log)
 
+            && encryption_key_get_latest_version(FIL_DEFAULT_ENCRYPTION_KEY)
 
+            == ENCRYPTION_KEY_VERSION_INVALID) {
 
+               sql_print_error("InnoDB: cannot enable encryption, "
 
+                               "encryption plugin is not available");
 
+               goto error;
 
+       }
 
+
 
        os_innodb_umask = (ulint) my_umask;
 
 
        /* First calculate the default path for innodb_data_home_dir etc.,

And now I get a crash with --innodb-encryption-threads=4 but without --innodb-encrypt-tables. Assert in buf_page_io_complete(), because the page is corrupted. And the page is considered corrupted in here:

	/* declare empty pages non-corrupted */
 
	if (checksum_field1 == 0 && checksum_field2 == 0
 
	    && *reinterpret_cast<const ib_uint64_t*>(read_buf +
 
						     FIL_PAGE_LSN) == 0) {
 
		/* make sure that the page is really empty */
 
		for (ulint i = 0; i < UNIV_PAGE_SIZE; i++) {
 
			if (read_buf[i] != 0) {
 
				return(TRUE);
 
			}
 
		}
 
		return(FALSE);
 
	}

Because the page looks like this:

(gdb) p read_buf[0] @ UNIV_PAGE_SIZE
 
$1 = '\000' <repeats 32 times>, "\262\326", '\000' <repeats 16349 times>

Comment by Jan Lindström (Inactive) [ 2015-05-11 ]

Could not easily repeat with above fix. Possible fix candidate anyway:

diff --git a/storage/xtradb/handler/ha_innodb.cc b/storage/xtradb/handler/ha_innodb.cc
 
index 47659fb..c89e317 100644
 
--- a/storage/xtradb/handler/ha_innodb.cc
 
+++ b/storage/xtradb/handler/ha_innodb.cc
 
@@ -3633,6 +3633,21 @@ innobase_init(
 
        }
 
 #endif
 
 
+       if ((srv_encrypt_tables || srv_encrypt_log)
 
+               && encryption_key_get_latest_version(FIL_DEFAULT_ENCRYPTION_KEY)
 
+               == ENCRYPTION_KEY_VERSION_INVALID) {
 
+               sql_print_error("InnoDB: cannot enable encryption, "
 
+                       "encryption plugin is not available");
 
+               goto error;
 
+       }
 
+
 
+       if (!srv_encrypt_tables && srv_n_fil_crypt_threads) {
 
+               ib_logf(IB_LOG_LEVEL_INFO, "encryption disabled, "
 
+                       "setting number of encryption threads to 0");
 
+               srv_n_fil_crypt_threads = 0;
 
+       }
 
+
 
+

Comment by Sergei Golubchik [ 2015-05-11 ]

Cannot repeat this anymore. May be it as a broken build or some later change fixed it.

Generated at Thu Feb 08 07:24:00 UTC 2024 using Jira 8.20.16#820016-sha1:9d11dbea5f4be3d4cc21f03a88dd11d8c8687422.