CentOS release 6.9

Upgrade to 10.2.9 did not help either.

jplindst, could you please take a look?

Any ideas on this? This occurs every time in our multiuser tests. We are using 10.2.9.
Do you need any additional info?

So it is waiting asyncronous rollback to finish and I see also log fsync on other thread, but do not see any errors on error log. There is few simple inserts and then insert into select, is that a huge table?

From the latest occurrence looks like worker-thread which hanged on INSERT keeps running in infinite loop:

│1548 /**
│1549 Wait for the asynchronous rollback to complete, if it is in progress */
│1550 static void wait(trx_t* trx)
...
│1558 while (is_forced_rollback(trx)) {
│1559
│1560 /* Wait for the async rollback to complete */
│1561
│1562 trx_mutex_exit(trx);
│1563
│1564 loop_count++;
│1565 /* If the wait is long, don't hog the cpu. */
│1566 if (loop_count < 100)

else if (loop_count < 1000)

else

│1576
│1577 os_thread_sleep(sleep_time);
│1578
│1579 trx_mutex_enter(trx);
│1580 }
...
(gdb) p loop_count
$31 = 184010

(gdb) p/x trx->in_innodb
$34 = 0xffffffff

Does this mean that trx->in_innodb erroneusly dropped below zero value at some point?

Attached call stack, trx and thd prints - mysqld_hanged_20171108.txt.

fsync() mentioned in earlier comment gets back from OS with ret=0, as there innodb_buffer_pool_instances=64 fsyncs called quite frequently.

Notice - transaction which hanged did not have failed SQLs, at least visible to the client, this is what we see from our application log:

"START TRANSACTION" at Wed Nov 08 16:52:50 2017
"UPDATE subrack SET aliasname=aliasname WHERE subrack.nid = 1 AND subrack.srkpos = 1" at Wed Nov 08 16:52:50 2017
"UPDATE unit SET unstate=3 WHERE unit.nid = 1 AND unit.unnr = 74" at Wed Nov 08 16:52:50 2017
"UPDATE module SET mstate=3 WHERE module.nid = 1 AND module.unnr = 74 AND module.mpos = 0" at Wed Nov 08 16:52:50 2017
"UPDATE module SET mstate=3 WHERE module.nid = 1 AND module.unnr = 74 AND module.mpos = 11" at Wed Nov 08 16:52:50 2017
"UPDATE module SET mstate=3 WHERE module.nid = 1 AND module.unnr = 74 AND module.mpos = 12" at Wed Nov 08 16:52:50 2017
"UPDATE module SET mstate=3 WHERE module.nid = 1 AND module.unnr = 74 AND module.mpos = 13" at Wed Nov 08 16:52:50 2017
"UPDATE module SET mstate=3 WHERE module.nid = 1 AND module.unnr = 74 AND module.mpos = 14" at Wed Nov 08 16:52:50 2017
"UPDATE module SET mstate=3 WHERE module.nid = 1 AND module.unnr = 74 AND module.mpos = 15" at Wed Nov 08 16:52:50 2017
"UPDATE module SET mstate=3 WHERE module.nid = 1 AND module.unnr = 74 AND module.mpos = 16" at Wed Nov 08 16:52:50 2017
"UPDATE module SET mstate=3 WHERE module.nid = 1 AND module.unnr = 74 AND module.mpos = 17" at Wed Nov 08 16:52:50 2017

this one is hanging ===> UPDATE module SET mstate=3 WHERE module.nid = 1 AND module.unnr = 74 AND module.mpos = 19

After 10 hours worker thread in the same loop inside TrxInInnoDB::wait:

(gdb) p loop_count
$1 = 541217
(gdb) p trx->in_innodb
$2 = 4294967295
(gdb) p/x trx->in_innodb
$3 = 0xffffffff

Looks like this condition is always evaluated to true causing infinite loop:
/*
@return true if it is a forced rollback, asynchronously */
static bool is_forced_rollback(const trx_t* trx)

In the latest bug occurrence have seen that same transaction context variable was accessed by two worker threads simultaneously (threads 25 and 12).

Checked that these two threads were handling different connections and different transactions, however they clash often on the same InnoDB tables doing a lot of selects and updates/inserts/deletes.

Somehow this situation ends up in a wrong decrement in thread 25:

Breakpoint 1 at 0x5586b5469e38: file /coriant/mariadb/10.2.10/storage/innobase/include/trx0trx.h, line 1532.

if (-trx>in_depth)

trx_mutex_enter(trx);
===> ut_ad((trx->in_innodb & TRX_FORCE_ROLLBACK_MASK) > 0);
-trx>in_innodb;

(gdb) thr 25
...
(gdb) p trx->in_depth
$20 = 1
(gdb) p trx->in_innodb
$21 = 0
(gdb) p trx
$22 = (trx_t *) 0x7f61594df418

next operation -trx>in_innodb will make the erroneous decrement:

trx->in_innodb 0 => 0xffffffff

Attached backtraces from these threads taken from gdb session, same transaction context (trx=0x7f61594df418) seen on both stacks - see gdb_mysqld_20171123.txt

Maybe trx->in_depth variable increment/decrement isn't protected/non-atomic and thus is the subject to race conditions=>root cause for this and similar bugs?

Probably related to MDEV-14336 (Deadlock at unlocking tables when local server and replication write to same table).

I believe I'm experiencing the same issue. I'm developing a multi-threaded program were up to a dozen worker threads perform inserts & update on a table that can grow as large as 23 million rows, but tends to happen within the first hundred-thousand or so inserts/updates.

Testing with 10.2.8 to 10.2.11, I encounter hangs like this, but not with 10.0 or 10.1 (the current dev environment). I've been searching and trying to debug this for a couple of months, and have also tried the query cache & stats workaround, but nothing has helped. We would like to switch to 10.2 so we can make use of the JSON functions, but for now this is preventing us from switching from 10.1.

Please let me know if I can provide any debugging output that might help.

We face this issue every day after upgrading from 10.1 to 10.2. And because of using InnoDB row locking (`for update`) we have 20-30 records every day which are not accessible until we restart the database by killing the process of `mysqld`. (just running `systemctl restart mysql` doesn't work, we have to kill the process too. BTW `kill <thread-id>` doesn't work too, the state is changed to Killed but the thread/process is still running)
Sometimes it blocks some of the incoming queries (or makes the DB slower) so the number of connected threads keeps growing until it reaches to 100k threads and after that, MariaDB doesn't accept any new connections.

Also, we face the issue Alex said almost once in a week and I think it's related to this issue too. Because the queries are the same.
(https://jira.mariadb.org/browse/MDEV-14336)

This issue has become a serious issue for us. How can I help you to fix this issue sooner?

I just ran my tests three times with MySQL 5.7.20 and it ran without issue, so whatever is going on is specific to MariaDB 10.2.

My tests are also showing that this problem is present under MariaDB 10.3.3.

Any update on this issue?

I am now unable to replicate my particular issue after the release of 10.2.13. I think this has been fixed by MDEV-15029.

I didn't create this issue, so I cannot speak for the original author, but if we were both experiencing the same issue, this should be fixed for the others who have posted here as well.

After updating to 10.2.13, we still face this issue (However, it's an update query, not an insert query). Also, we have some update, insert and even select queries stuck in state 'NULL' too and we can't kill them. (Maybe it's related to the issue MDEV-15217)

As I said before, because of using pessimistic locking (FOR UPDATE), the records won't be accessible until we restart the database.

After updating to 10.2.13, we still face this issue as well. It is now an update query stuck in state 'query end'.

Yeps, here is more details from latest occurrence - mysqld_10_2_13_hanged_spid_65.zip

Again spinning in the infinite loop here:

Thread 12 (Thread 0x7fe6c4b0f700 (LWP 4424)):
#0 0x00007ffff7bcde4d in nanosleep () from /lib64/libpthread.so.0
#1 0x0000555555e1e2c0 in os_thread_sleep (tm=<optimized out>) at /home/buildbot/buildbot/padding_for_CPACK_RPM_BUILD_SOURCE_DIRS_PREFIX/mariadb-10.2.13/storage/innobase/os/os0thread.cc:230
#2 0x0000555555db0e4c in wait (trx=0x7fffe4032098) at /home/buildbot/buildbot/padding_for_CPACK_RPM_BUILD_SOURCE_DIRS_PREFIX/mariadb-10.2.13/storage/innobase/include/trx0trx.h:1577
#3 enter (disable=false, trx=0x7fffe4032098) at /home/buildbot/buildbot/padding_for_CPACK_RPM_BUILD_SOURCE_DIRS_PREFIX/mariadb-10.2.13/storage/innobase/include/trx0trx.h:1504
#4 TrxInInnoDB (disable=false, trx=<optimized out>, this=<synthetic pointer>) at /home/buildbot/buildbot/padding_for_CPACK_RPM_BUILD_SOURCE_DIRS_PREFIX/mariadb-10.2.13/storage/innobase/include/trx0trx.h:1397
#5 innobase_xa_prepare (hton=<optimized out>, thd=0x7fe5a00009a8, prepare_trx=<optimized out>) at /home/buildbot/buildbot/padding_for_CPACK_RPM_BUILD_SOURCE_DIRS_PREFIX/mariadb-10.2.13/storage/innobase/handler/ha_innodb.cc:17630
#6 0x0000555555bc8170 in prepare_or_error (all=false, thd=0x7fe5a00009a8, ht=0x5555573c1d98) at /home/buildbot/buildbot/padding_for_CPACK_RPM_BUILD_SOURCE_DIRS_PREFIX/mariadb-10.2.13/sql/handler.cc:1158
#7 ha_commit_trans (thd=thd@entry=0x7fe5a00009a8, all=all@entry=false) at /home/buildbot/buildbot/padding_for_CPACK_RPM_BUILD_SOURCE_DIRS_PREFIX/mariadb-10.2.13/sql/handler.cc:1437
#8 0x0000555555b10307 in trans_commit_stmt (thd=thd@entry=0x7fe5a00009a8) at /home/buildbot/buildbot/padding_for_CPACK_RPM_BUILD_SOURCE_DIRS_PREFIX/mariadb-10.2.13/sql/transaction.cc:510
#9 0x0000555555a31285 in mysql_execute_command (thd=<optimized out>) at /home/buildbot/buildbot/padding_for_CPACK_RPM_BUILD_SOURCE_DIRS_PREFIX/mariadb-10.2.13/sql/sql_parse.cc:6273
#10 0x0000555555a4c88e in Prepared_statement::execute (this=this@entry=0x7fe5a0006148, expanded_query=expanded_query@entry=0x7fe6c4b0dfa0, open_cursor=open_cursor@entry=false) at /home/buildbot/buildbot/padding_for_CPACK_RPM_BUILD_SOURCE_DIRS_PREFIX/mariadb-10.2.13/sql/sql_prepare.cc:4773
#11 0x0000555555a4caf0 in Prepared_statement::execute_loop (this=0x7fe5a0006148, expanded_query=0x7fe6c4b0dfa0, open_cursor=false, packet_end=<optimized out>, packet=<optimized out>) at /home/buildbot/buildbot/padding_for_CPACK_RPM_BUILD_SOURCE_DIRS_PREFIX/mariadb-10.2.13/sql/sql_prepare.cc:4203
#12 0x0000555555a4d937 in mysql_stmt_execute_common (thd=thd@entry=0x7fe5a00009a8, stmt_id=621106, packet=packet@entry=0x7fe5a0ae50d2 "", packet_end=packet_end@entry=0x7fe5a0ae50d2 "", cursor_flags=0, bulk_op=bulk_op@entry=false, read_types=read_types@entry=false) at /home/buildbot/buildbot/padding_for_CPACK_RPM_BUILD_SOURCE_DIRS_PREFIX/mariadb-10.2.13/sql/sql_prepare.cc:3205
#13 0x0000555555a4d9c7 in mysqld_stmt_execute (thd=thd@entry=0x7fe5a00009a8, packet_arg=packet_arg@entry=0x7fe5a0ae50c9 "2z\t", packet_length=packet_length@entry=9) at /home/buildbot/buildbot/padding_for_CPACK_RPM_BUILD_SOURCE_DIRS_PREFIX/mariadb-10.2.13/sql/sql_prepare.cc:3103
#14 0x0000555555a3c428 in dispatch_command (command=command@entry=COM_STMT_EXECUTE, thd=thd@entry=0x7fe5a00009a8, packet=packet@entry=0x7fe5a0ae50c9 "2z\t", packet_length=packet_length@entry=9, is_com_multi=is_com_multi@entry=false, is_next_command=is_next_command@entry=false) at /home/buildbot/buildbot/padding_for_CPACK_RPM_BUILD_SOURCE_DIRS_PREFIX/mariadb-10.2.13/sql/sql_parse.cc:1748
#15 0x0000555555a3d999 in do_command (thd=0x7fe5a00009a8) at /home/buildbot/buildbot/padding_for_CPACK_RPM_BUILD_SOURCE_DIRS_PREFIX/mariadb-10.2.13/sql/sql_parse.cc:1360
#16 0x0000555555b0223a in do_handle_one_connection (connect=connect@entry=0x5555f4d0fea8) at /home/buildbot/buildbot/padding_for_CPACK_RPM_BUILD_SOURCE_DIRS_PREFIX/mariadb-10.2.13/sql/sql_connect.cc:1335
#17 0x0000555555b0235d in handle_one_connection (arg=arg@entry=0x5555f4d0fea8) at /home/buildbot/buildbot/padding_for_CPACK_RPM_BUILD_SOURCE_DIRS_PREFIX/mariadb-10.2.13/sql/sql_connect.cc:1241
#18 0x0000555555d7a90d in pfs_spawn_thread (arg=0x5555f4464b88) at /home/buildbot/buildbot/padding_for_CPACK_RPM_BUILD_SOURCE_DIRS_PREFIX/mariadb-10.2.13/storage/perfschema/pfs.cc:1862
#19 0x00007ffff7bc6e25 in start_thread () from /lib64/libpthread.so.0
#20 0x00007ffff619e34d in clone () from /lib64/libc.so.6

After upgrading from MariaDB 2.10.6 to 2.10.13 we started experiencing this issue. INSERT queries getting stuck in state Unlocking tables. We had one case of UPDATE query getting stuck in init state it might or might not be the same issue.

@YURII KANTONISTOV, comparing to Percona and Mysql source codes, the file "storage/innobase/include/trx0trx.h" is a little bit different:

MariaDB 10.2.13 - https://github.com/MariaDB/server/blob/mariadb-10.2.13/storage/innobase/include/trx0trx.h#L1496

	static void enter(trx_t* trx, bool disable)

	{

		if (srv_read_only_mode) {

			return;

		}

		ut_ad(!is_async_rollback(trx));

		/* If it hasn't already been marked for async rollback.

		and it will be committed/rolled back. */

		if (disable) {

			trx_mutex_enter(trx);

			if (!is_forced_rollback(trx)

			    && is_started(trx)

			    && !trx_is_autocommit_non_locking(trx)) {

				ut_ad(trx->killed_by == 0);

				/* This transaction has crossed the point of

				no return and cannot be rolled back

				asynchronously now. It must commit or rollback

				synhronously. */

				trx->in_innodb |= TRX_FORCE_ROLLBACK_DISABLE;

			}

			trx_mutex_exit(trx);

		}

		/* Avoid excessive mutex acquire/release */

		if (trx->in_depth++) {

			/* The transaction is already inside InnoDB. */

			return;

		}

		trx_mutex_enter(trx);

		wait(trx);

		ut_ad((trx->in_innodb & TRX_FORCE_ROLLBACK_MASK) == 0);

		++trx->in_innodb;

		trx_mutex_exit(trx);

	}

	/**

	Note that we are exiting InnoDB code */

	static void exit(trx_t* trx)

	{

		if (srv_read_only_mode) {

			return;

		}

		/* Avoid excessive mutex acquire/release */

		ut_ad(trx->in_depth > 0);

		if (--trx->in_depth) {

			return;

		}

		trx_mutex_enter(trx);

		ut_ad((trx->in_innodb & TRX_FORCE_ROLLBACK_MASK) > 0);

		--trx->in_innodb;

		trx_mutex_exit(trx);

	}

Percona 5.7 - https://github.com/percona/percona-server/blob/5.7/storage/innobase/include/trx0trx.h#L1465

	/**

	Note that we have crossed into InnoDB code.

	@param[in] disable	true if called from COMMIT/ROLLBACK method */

	static void enter(trx_t* trx, bool disable)

	{

		if (srv_read_only_mode) {

			return;

		}

		ut_ad(!is_async_rollback(trx));

		/* If it hasn't already been marked for async rollback.

		and it will be committed/rolled back. */

		if (disable) {

			trx_mutex_enter(trx);

			if (!is_forced_rollback(trx)

			    && is_started(trx)

			    && !trx_is_autocommit_non_locking(trx)) {

				ut_ad(trx->killed_by == 0);

				/* This transaction has crossed the point of

				no return and cannot be rolled back

				asynchronously now. It must commit or rollback

				synhronously. */

				trx->in_innodb |= TRX_FORCE_ROLLBACK_DISABLE;

			}

			trx_mutex_exit(trx);

		}

		/* Avoid excessive mutex acquire/release */

		++trx->in_depth;

		/* If trx->in_depth is greater than 1 then

		transaction is already in InnoDB. */

		if (trx->in_depth > 1) {

			return;

		}

		/* Only the owning thread should release the latch. */

		trx_search_latch_release_if_reserved(trx);

		trx_mutex_enter(trx);

		wait(trx);

		ut_ad((trx->in_innodb & TRX_FORCE_ROLLBACK_MASK) == 0);

		++trx->in_innodb;

		trx_mutex_exit(trx);

	}

	/**

	Note that we are exiting InnoDB code */

	static void exit(trx_t* trx)

	{

		if (srv_read_only_mode) {

			return;

		}

		/* Avoid excessive mutex acquire/release */

		ut_ad(trx->in_depth > 0);

		--trx->in_depth;

		if (trx->in_depth > 0) {

			return;

		}

		/* Only the owning thread should release the latch. */

		trx_search_latch_release_if_reserved(trx);

		trx_mutex_enter(trx);

		ut_ad((trx->in_innodb & TRX_FORCE_ROLLBACK_MASK) > 0);

		--trx->in_innodb;

		trx_mutex_exit(trx);

	}

Mysql 5.7 - https://github.com/mysql/mysql-server/blob/5.7/storage/innobase/include/trx0trx.h#L1431

	static void enter(trx_t* trx, bool disable)

	{

		if (srv_read_only_mode) {

			return;

		}

		ut_ad(!is_async_rollback(trx));

		/* If it hasn't already been marked for async rollback.

		and it will be committed/rolled back. */

		if (disable) {

			trx_mutex_enter(trx);

			if (!is_forced_rollback(trx)

			    && is_started(trx)

			    && !trx_is_autocommit_non_locking(trx)) {

				ut_ad(trx->killed_by == 0);

				/* This transaction has crossed the point of

				no return and cannot be rolled back

				asynchronously now. It must commit or rollback

				synhronously. */

				trx->in_innodb |= TRX_FORCE_ROLLBACK_DISABLE;

			}

			trx_mutex_exit(trx);

		}

		/* Avoid excessive mutex acquire/release */

		++trx->in_depth;

		/* If trx->in_depth is greater than 1 then

		transaction is already in InnoDB. */

		if (trx->in_depth > 1) {

			return;

		}

		/* Only the owning thread should release the latch. */

		trx_search_latch_release_if_reserved(trx);

		trx_mutex_enter(trx);

		wait(trx);

		ut_ad((trx->in_innodb & TRX_FORCE_ROLLBACK_MASK) == 0);

		++trx->in_innodb;

		trx_mutex_exit(trx);

	}

	/**

	Note that we are exiting InnoDB code */

	static void exit(trx_t* trx)

	{

		if (srv_read_only_mode) {

			return;

		}

		/* Avoid excessive mutex acquire/release */

		ut_ad(trx->in_depth > 0);

		--trx->in_depth;

		if (trx->in_depth > 0) {

			return;

		}

		/* Only the owning thread should release the latch. */

		trx_search_latch_release_if_reserved(trx);

		trx_mutex_enter(trx);

		ut_ad((trx->in_innodb & TRX_FORCE_ROLLBACK_MASK) > 0);

		--trx->in_innodb;

		trx_mutex_exit(trx);

	}

I'm not familiar with MariaDB/MySQL/Percona source codes, but can these differences cause this/these issue(s)?

In addition, we also have queries stuck in "query end" and "init" states too.

If this will be of any help - some time ago we patched TrxInInnoDB::exit to get our internal testing done, see below, then hanging did not occur.

But this is just an ugly workaround, I believe real bug is somewhere else:

ut_ad((trx->in_innodb & TRX_FORCE_ROLLBACK_MASK) > 0);
-trx>in_innodb;

=>

ut_ad((trx->in_innodb & TRX_FORCE_ROLLBACK_MASK) > 0);
if( ( trx->in_innodb & TRX_FORCE_ROLLBACK_MASK ) == 0 )

else

As far as I can tell, the TRX_FORCE_ROLLBACK_MASK is dead code in MariaDB 10.2. The reason is that unlike MySQL 5.7, MariaDB 10.2 does not implement the function thd_tx_priority() or the field THD::thd_tx_priority. Because in MariaDB 10.2 thd_trx_priority() always returns 0, also trx_is_high_priority() will always return false and DeadlockChecker::select_victim() will never invoke trx_arbitrate().

jplindst, please explain how you think that reverting this code cleanup that was done as part of MDEV-11197 would fix the problem? Is there a repeatable test case?

Wouldn’t it make more sense to remove the dead code altogether?

In fact, the field trx_t::in_depth should be unnecessary in MariaDB. It was added in MySQL 5.7.6 as part of WL#6835: InnoDB: GCS Replication: Deterministic Deadlock Handling (High Prio Transactions in InnoDB), which is Oracle’s response to Galera multi-master replication.

Also the class TrxInInnoDB was added as part of WL#6835, in MySQL 5.7.5 already.

I think that the proper fix should be to carefully revert all WL#6835 code from MariaDB.

This appears to be the merge of WL#6835 to MySQL 5.7.6 (5,485 lines of diff to the first parent; 3,570 lines of that in InnoDB code). There are many follow-up fixes, but it might be easiest to try to revert the initial merge and resolve the conflicts. This could also lead to the right track regarding this hang.

Reverting this merge would remove the fields trx_t::in_depth and trx_t::in_innodb and the class TrxInInnoDB. I have the feeling that this instrumentation is very unforgiving and fragile. Maybe some rare code paths were not adjusted when this code was merged to MariaDB 10.2.2 in the first place?

I wonder if the hangs could be due to two other changes:

1. innodb_lock_schedule_algorithm=VATS in MariaDB 10.2.3
2. MDEV-14637 Latching order violation during btr_cur_pessimistic_delete()

To rule out the former, I would suggest testing with innodb_lock_schedule_algorithm=fcfs.
For the hang due to SX-locks (MDEV-14637), there is no workaround. I did not attempt to revert the code that was introduced in MySQL 5.7.1, because it would cause a significant performance regression.

As always, if InnoDB hangs, without having stack traces of all threads (thread apply all backtrace from gdb) it is very difficult to guess what is going on.

It looks like innodb_lock_schedule_algorithm=vats would corrupt the lock data structures when lock_rec_insert_by_trx_age() is invoked on a lock on a SPATIAL INDEX. It seems that it can only deal with B-tree indexes.

To rule out the former, I would suggest testing with innodb_lock_schedule_algorithm=fcfs.

We've already tested it, it didn't work.

I pushed a revert of WL#6835 and some other cleanup to bb-10.2-marko. This will require thorough testing and review.

marko My intention was not to push that change to 10.2 but my staging branch instead. There is at least one stack on this issue and that is not in VATS code instead it is spinning on trx0trx.h in wait() function. I have been trying to repeat with rqg but failed

The TrxInInnoDB::wait() as well as the whole TrxInInnoDB and a lot of related code were removed in my patch. I had to push a follow-up fix to unbreak the build. Surprisingly, there are no related-looking test failures on buildbot so far. But, this would have to be tested very carefully, and especially the changes in lock0lock.cc would have to be reviewed thoroughly.

When comparing the lock0lock.cc code to MySQL 5.7, I found some potential hang sources, such as the lock_grant() that was changed by the innodb_lock_schedule_algorithm=VATS patch. I will push a revised set of commits to bb-10.2-marko shortly.

I have now pushed this to 10.2. Some WSREP related cleanup I pushed to 10.1.
It turns out that MariaDB 10.2 uses a different mechanism for asynchronously killing transactions; see my follow-up fix in 10.1 after porting the cleanup from 10.2. In 10.2, the function thd_report_wait_for() has apparently been replaced with thd_rpl_deadlock_check().

Since we've updated to 10.2.14, we haven't faced this issue. Also, the average response time of our endpoints is decreased by 100-150%. Thank you all

10.2.14 has solved the issue. Thank you very much.

We faced the same issue, but Galera
MariaDB 10.2.13
It has been resolved too?

matteraf, Galera is using InnoDB underneath, and the InnoDB in MariaDB Server contains some related modifications (WSREP patches, for write-set replication). Most of the Galera-related changes in InnoDB have something to do with record locking. So yes, it looks like you were affected by exactly this issue. The hang was caused by new code that was introduced in MySQL 5.7 (and merged to MariaDB 10.2) for Galera-like functionality in MySQL 5.7. This code was mostly dead code, because some related callback functions were replaced with stubs in MariaDB. So, it was safe to revert those changes. The hang was caused by something in the class TrxInInnoDB that was part of the added 5.7 code. I did not study the exact mechanism. Now that the unnecessary 5.7 code has been removed from MariaDB, it is safe to say that this hang is not possible any more.