Details
-
Bug
-
Status: Closed (View Workflow)
-
Major
-
Resolution: Fixed
-
5.5(EOL), 10.0(EOL), 10.1(EOL)
-
None
Description
InnoDB sets THD::ha_data as following:
static inline
|
trx_t*&
|
thd_to_trx(
|
/*=======*/
|
THD* thd) /*!< in: MySQL thread */
|
{
|
return(*(trx_t**) thd_ha_data(thd, innodb_hton_ptr));
|
}
|
|
static inline
|
trx_t*
|
check_trx_exists(
|
/*=============*/
|
THD* thd) /*!< in: user thread handle */
|
{
|
trx_t*& trx = thd_to_trx(thd);
|
|
if (trx == NULL) {
|
trx = innobase_trx_allocate(thd);
|
} else if (UNIV_UNLIKELY(trx->magic_n != TRX_MAGIC_N)) {
|
mem_analyze_corruption(trx);
|
ut_error;
|
}
|
|
innobase_trx_init(thd, trx);
|
|
return(trx);
|
}
|
This is unsafe, because nothing prevents InnoDB plugin from being uninstalled while there's active transaction. This can cause crashes and any other odd behavior. It may also corrupt stack, as functions pointers are not available after dlclose. E.g. spider has similar bug and outcome was like MDEV-7914.
To reproduce this it should be enough to have one thread with active InnoDB transaction, no InnoDB tables in table cache and one thread issuing UNINSTALL PLUGIN innodb.
The fix is to use thd_set_ha_data() when manipulating per-connection handler data. It does appropriate plugin locking.
Attachments
Issue Links
- relates to
-
MDEV-7914 spider/bg.ha, spider/bg.ha_part crash server sporadically in buildbot
- Closed