Details
-
Bug
-
Status: Closed (View Workflow)
-
Major
-
Resolution: Fixed
-
10.2(EOL)
Description
MariaDB Server 10.2 lacks this race condition bug fix from Oracle:
commit 565d20b44f24fcc855dc616164d87b03cfad10bc
|
Author: Jon Olav Hauglid <jon.hauglid@oracle.com>
|
Date: Thu Mar 6 12:15:07 2014 +0100
|
|
Bug#17606098: DEADLOCK INVOLVING SRV_MONITOR_THREAD AND LOCK_THD_DATA
|
|
This deadlock involved LOCK_thd_data and InnoDB's trx_sys mutex.
|
It could occur if InnoDB code (e.g. the srv_monitor_thread) called
|
thd_security_context() while having trx_sys locked and at the same time
|
the server tried to notify InnoDB about a deadlock (which involves calling
|
mysql_lock_abort_for_thread() while holding LOCK_thd_data).
|
This could lead to deadlock if mysql_lock_abort_for_thread() lead to
|
trx_allocate_for_mysql() being called inside InnoDB.
|
|
This very rarely happens - the problem was found with RQG and is very
|
difficult to reproduce.
|
|
This patch solves the problem by splitting LOCK_thd_data so that a
|
separate new mutex LOCK_thd_query protects the query string
|
accessed by thd_security_context().
|
|
The patch also strengthens the protection of the query string by
|
enforcing that it can only be set by the owner thread and that this
|
requires locking of LOCK_thd_query. Reading the query string can
|
be done by the owner thread without holding LOCK_thd_query but
|
other threads reading the query string have to have LOCK_thd_query
|
locked.
|
|
This also solves a separate problem where other threads could
|
read the query string while it was being deleted by the owner thread.
|
|
Finally, the patch updates the performance schema mutex
|
heuristics - including correcting an issue introduced by WL#6369.
|
Only the InnoDB part of this patch was merged, with a mock-up version of innobase_get_stmt_safe().
Attachments
Issue Links
- relates to
-
MDEV-11641 innobase_get_stmt_safe() does not copy the last byte of thd->query_string
- Closed
-
MDEV-13196 Remove handler::store_lock()
- Open