Details
-
Bug
-
Status: Closed (View Workflow)
-
Major
-
Resolution: Fixed
-
10.5, 10.6, 10.11, 11.4
Description
Starting with MDEV-8139, fil_space_t is no longer trivially constructible. In fil_space_t::create(), the object is being constructed using the following antipattern:
/* FIXME: if calloc() is defined as an inline function that calls |
memset() or bzero(), then GCC 6 -flifetime-dse can optimize it away */
|
*after = space = new (ut_zalloc_nokey(sizeof(*space))) fil_space_t; |
|
space->id = id;
|
|
UT_LIST_INIT(space->chain, &fil_node_t::chain);
|
|
space->purpose = purpose;
|
space->flags = flags;
|
This needs to be refactored to an explicit fil_space_t::fil_space_t(), which will initialize all data fields, something like the following:
*after = space = new (ut_malloc_nokey(*space)) fil_space_t(id, flags, purpose, crypt_data, mode);
|
The fil_space_t::latch member will need some special care, because outside SUX_LOCK_GENERIC the implementation expects that the object be zero-initialized.
Attachments
Issue Links
- is caused by
-
MDEV-8139 Fix scrubbing
- Closed
- relates to
-
MDEV-18749 rec_get_converted_size_comp_prefix_low: Conditional jump or move depends on uninitialised value upon adding FULLTEXT index
- Closed
-
MDEV-34625 MariaDB server crashes in 10.11.8 due to using uninitialized member variables
- Closed
-
MDEV-35472 Server crash in ha_storage_put_memlim upon reading from INNODB_LOCKS
- Closed
-
MDEV-35618 Bogus assertion failure 'recv_sys.scanned_lsn < max_lsn + 32 * 512U' during recovery
- Closed