Bug #81628 Assertion failure in 'MYSQL_BIN_LOG::prepare()' if DML is passed in --init-file
Submitted: 27 May 2016 17:25 Modified: 8 Aug 2016 15:48
Reporter: Deepthi Eranti Sreenivas Email Updates:
Status: Closed Impact on me:
None 
Category:MySQL Server: Replication Severity:S3 (Non-critical)
Version:5.7.14 OS:Any
Assigned to: CPU Architecture:Any

[27 May 2016 17:25] Deepthi Eranti Sreenivas
Description:
In the main.initialize_gtid test,$BOOTSTRAP_SQL file is created which has the following commands:

CREATE DATABASE test;
CREATE TABLE test.t1(a INT) ENGINE=innodb;
Begin;
INSERT INTO test.t1 VALUES (1);
Commit;
DROP TABLE test.t1;
DROP DATABASE test;

This file is passed during initialization as :

--exec $MYSQLD $extra_args --initialize-insecure --datadir=$DDIR $init_args --init-file=$BOOTSTRAP_SQL > $MYSQLD_LOG 2>&1

The above command fails to succeed with the following assertion failure for  "INSERT INTO test.t1 VALUES (1);" query

Contents of $MYSQLD_LOG
=========================
2016-05-20T15:22:05.961882Z 0 [Warning] InnoDB: New log files created, LSN=45790
2016-05-20T15:22:06.522586Z 0 [Warning] InnoDB: Creating foreign key constraint system tables.
2016-05-20T15:22:06.614925Z 0 [Warning] No existing UUID has been found, so we assume that this is the first time that this server has been started. Generating a new UUID: 9cd375ca-1e9e-11e6-a140-0021f62e9727.
2016-05-20T15:22:06.616575Z 0 [Warning] Gtid table is not ready to be used. Table 'mysql.gtid_executed' cannot be opened.
2016-05-20T15:22:06.620957Z 1 [Warning] root@localhost is created with an empty password ! Please consider switching off the --initialize-insecure option.
mysqld-debug: PATH/TO/sql/binlog.cc:7923: virtual int MYSQL_BIN_LOG::prepare(THD*, bool): Assertion `thd->slave_thread ? opt_log_slave_updates : thd->variables.sql_log_bin' failed.
15:22:09 UTC - mysqld got signal 6 ;
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.
Attempting to collect some information that could help diagnose the problem.
As this is a crash and something is definitely wrong, the information
collection process might fail.

key_buffer_size=8388608
read_buffer_size=131072
max_used_connections=0
max_threads=151
thread_count=1
connection_count=0
It is possible that mysqld could use up to
key_buffer_size + (read_buffer_size + sort_buffer_size)*max_threads = 68196 K  bytes of memory
Hope that's ok; if not, decrease some variables in the equation.

Thread pointer: 0x4b293e0
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 = 7fe3035fdcb8 thread_stack 0x40000
PATH/TO/bin/mysqld-debug(my_print_stacktrace+0x35)[0x17eb30e]
PATH/TO/mysqld-debug(handle_fatal_signal+0x415)[0xdc0f52]
/lib64/libpthread.so.0(+0xf130)[0x7fe33c2c0130]
/lib64/libc.so.6(gsignal+0x39)[0x7fe33aec35c9]
/lib64/libc.so.6(abort+0x148)[0x7fe33aec4cd8]
/lib64/libc.so.6(+0x2e536)[0x7fe33aebc536]
/lib64/libc.so.6(+0x2e5e2)[0x7fe33aebc5e2]
PATH/TO/bin/mysqld-debug[0x1759a83]
PATH/TO/mysqld-debug(_Z15ha_commit_transP3THDbb+0x541)[0xe3f890]
PATH/TO/bin/mysqld-debug(_Z17trans_commit_stmtP3THD+0xd6)[0x1599b1e]
PATH/TO/bin/mysqld-debug(_Z21mysql_execute_commandP3THDb+0x7b41)[0x1498fb7]
PATH/TO/bin/mysqld-debug(_Z11mysql_parseP3THDP12Parser_state+0x540)[0x149a4bb]
PATH/TO/bin/mysqld-debug[0xdf2253]
PATH/TO/bin/mysqld-debug(handle_bootstrap+0xce)[0xdf24ca]
PATH/TO/bin/mysqld-debug(pfs_spawn_thread+0x173)[0x188e131]
/lib64/libpthread.so.0(+0x7df3)[0x7fe33c2b8df3]
/lib64/libc.so.6(clone+0x6d)[0x7fe33af8447d]

Trying to get some variables.
Some pointers may be invalid and cause the dump to abort.
Query (4b2c9a0): INSERT INTO test.t1 VALUES (1);
Connection ID (thread ID): 1
Status: NOT_KILLED

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.

How to repeat:
1. Download the binaries from http://pb2.no.oracle.com/?template=show_pushes&branch=mysql-5.7
2. Execute the test as 
	./mtr main.initialize_gtid --debug-server

Failure link :
http://pb2.no.oracle.com/?template=mysql_show_test_failure&search=yes&push_id
=9482753&test_id=9482924&test_run=n_mix-debug&test_suite=main&
test_case=initialize_gtid

The test passes if DML is removed from the $BOOTSTRAP_SQL.
[8 Aug 2016 15:48] David Moss
Posted by developer:
 
Thank you for your feedback, this has been fixed in upcoming versions and the following was added to the 5.7.14 changelog:
The initialize process now checks if the binary log is enabled while processing a compiled statement. In such cases it disables binary logging.