I modified the command line in description, it was mistakenly copied from the slave startup. All options are the same, and the disclaimer about useless slave options applies, only server_id, port and datadir location were different – those I fixed to avoid confusion.

I was able to reproduce with the supplied binlog file in a mysql-test-run test case

Very likely has something to do with my table cache patches.

OTOH it looks like temporary tables are in question. These don't go through table cache and must have table->in_use set to 0. Probably it is uninitialized?

Hmm... not really they should have proper in_use, but anyway crash doesn't seem to be relevant to table cache because it is temporary table.

There are multiple bugs visible from this report (thanks, btw!).

The lock wait timeout is a rather serious, and complex, issue with InnoDB row
locks. Below a small test case that reproduces it (not deterministic, may need
to be run a couple of times with --repeat to trigger the issue).

The problem is an INSERT and a DELETE on the same table. The DELETE blocks the
INSERT until commit, but the INSERT does not similarly block the DELETE. This
means that the INSERT can run first and group commit with the DELETE on the
master, but then on the slave, if the DELETE runs ahead, it will block the
INSERT, and the INSERT in turn will block the DELETE due to commit
ordering. The result is a deadlock.

--source include/have_innodb.inc
--source include/have_debug_sync.inc
--source include/have_debug_sync.inc
--source include/master-slave.inc

--connection slave
--source include/stop_slave.inc

--connection master
CREATE TABLE t1 (a INT PRIMARY KEY, b INT, KEY b_idx(b)) ENGINE=InnoDB;
INSERT INTO t1 VALUES (1,NULL), (2,2), (3,NULL), (4,4), (5, NULL), (6, 6);

1. Create a group commit with INSERT and DELETE, in that order.
   --connect (con1,127.0.0.1,root,,test,$SERVER_MYPORT_1,)
   SET debug_sync='commit_after_release_LOCK_prepare_ordered SIGNAL master_queued1 WAIT_FOR master_cont1';
   send INSERT INTO t1 VALUES (7, NULL);
   --connection master
   SET debug_sync='now WAIT_FOR master_queued1';

--connect (con2,127.0.0.1,root,,test,$SERVER_MYPORT_1,)
SET debug_sync='commit_after_release_LOCK_prepare_ordered SIGNAL master_queued2';
send DELETE FROM t1 WHERE b <= 3;

--connection master
SET debug_sync='now WAIT_FOR master_queued2';
SET debug_sync='now SIGNAL master_cont1';

--connection con1
REAP;
--connection con2
REAP;
SET debug_sync='RESET';
--save_master_pos

--connection slave
SET @old_parallel= @@GLOBAL.slave_parallel_threads;
SET GLOBAL slave_parallel_threads=16;
--source include/start_slave.inc
--sync_with_master

SELECT * FROM t1 ORDER BY a;

--source include/stop_slave.inc
SET GLOBAL slave_parallel_threads=@old_parallel;
--source include/start_slave.inc

--connection master
DROP TABLE t1;
--source include/rpl_end.inc

Ok, so I will close this as fixed.

There were several important issues found by this test:

1. A temporary table bug seen during shutdown (the assertion). Monty fixed
this in an earlier push to 10.0.

2. The MDEV-5921. This was reported also by nanyi607rao on
maria-developers@lists.launchpad.net, I have pushed a fix for this.

3. The MDEV-5914. This bug is still open, however I have pushed to 10.0 a
temporary fix that should be sufficient to make this bug disappear.

Please re-run the test to check that it is really fixed. I did at some point
see another error in the logs about temporary tables when I applied the
attached binlog. I cannot repeat it now, so it may have been another symptom
of the problem (1), but it would be good to get verification. I also did not
verify that the differences in rows between tables are gone, though fixing (2)
and (3) should fix it, hopefully.

This was a very good test, really important to get parallel replication ready
for end-users.