Details
-
Bug
-
Status: Open (View Workflow)
-
Major
-
Resolution: Unresolved
-
10.6, 10.11, 11.4, 11.8, 12.2(EOL), 12.3
-
None
-
None
Description
This was introduced in an attempt to fix MDEV-29575:
commit c0817dac99c28698dfc2b548d89acf1fb41dc32e
|
Author: Vlad Lesin <vlad_lesin@mail.ru>
|
Date: Fri Sep 30 19:38:59 2022 +0300
|
|
|
MDEV-29575 Access to innodb_trx, innodb_locks and innodb_lock_waits along with detached XA's can cause SIGSEGV
|
|
|
trx->mysql_thd can be zeroed-out between thd_get_thread_id() and
|
thd_query_safe() calls in fill_trx_row(). trx_disconnect_prepared() zeroes out
|
trx->mysql_thd. And this can cause null pointer dereferencing in
|
fill_trx_row().
|
|
|
fill_trx_row() is invoked from fetch_data_into_cache() under trx_sys.mutex.
|
|
|
Bug fix is in reseting trx_t::mysql_thd in trx_disconnect_prepared() under
|
trx_sys.mutex lock too.
|
|
|
MTR test case can't be created for the fix, as we need to wait for
|
trx_t::mysql_thd reseting in fill_trx_row() after trx_t::mysql_thd was
|
checked for null while trx_sys.mutex is held. But trx_t::mysql_thd must be
|
reset in trx_disconnect_prepared() under trx_sys.mutex. There will be deadlock.
|
It is true that "fill_trx_row() is invoked from fetch_data_into_cache() under trx_sys.mutex". However it also holds trx.mutex, which is the right mutex to protect trx members.
Another potential problem is that such transactions can be found via other lists, e.g. Deadlock::print() is called with transactions obtained from the lock_sys lists and thus they don't hold trx_sys.trx_list.mutex.
thread_safe_trx_ilist_t::freeze() and thread_safe_trx_ilist_t::unfreeze() should be removed.
Also trx_print() seems to be unused and should be removed?
Attachments
Issue Links
- is caused by
-
-
- Closed
-