MDEV-28315 Fix ASAN stack-buffer-overflow in String::copy_aligned
Starting since this commit 36cdd5c there is an ASAN
stack-buffer-overflow error because we append a NULL terminator
beyond the length of memory allocated.
a6f7c8e...
by
Rucha Deodhar <email address hidden>
MDEV-28762: recursive call of some json functions without stack control
Fixup to MDEV-28762. Fixes warnings about unused variable "stack_used_up"
during building with RelWithDebInfo
05a407b...
by
Daniel Lenski <email address hidden>
MDEV-28782: modify mariadb-tzinfo-to-sql to set 'wsrep*' variables appropriately in cases where Galera is not compiled in
In 3b662c6ebd26b54ce534d9e7451cdc31e6c0046c, it was discovered that the
values of the 'wsrep_is_on' and 'wsrep_cannot_replicate_tz' variables need
to be overridden for embedded builds to pass
However, there are other build configurations where these variables also
have NULL values. The mariadb-tzinfo-to-sql script (implemented in
sql/tztime.cc) can be slightly modified to set its 'wsrep_is_on' and
'wsrep_cannot_replicate_tz' variables more predictably in all such cases,
thus allowing the mysql_tzinfo_to_sql_symlink.test test to pass without
any special-casing for particular build types.
All new code of the whole pull request, including one or several files that
are either new files or modified ones, are contributed under the BSD-new
license. I am contributing on behalf of my employer Amazon Web Services,
Inc.
MDEV-28495 InnoDB corruption due to lack of file locking
Starting with commit da094188f60bf67e3d90227304a4ea256fe2630f (MDEV-24393),
MariaDB will no longer acquire advisory file locks on InnoDB data
files by default, because it would create a large number of
entries in Linux /proc/locks.
The motivation for acquiring the file locks is to prevent accidental
concurrent startup of multiple server processes on the same data files.
Such mistake still turns out to be relatively common, based on
corruption bug reports from the community.
To prevent corruption due to concurrent startup attempts, the
Aria storage engine would unconditionally acquire an advisory lock
on one of its log files.
Solution: InnoDB will always lock its system tablespace files.
(Ever since commit 685d958e38b825ad9829be311f26729cccf37c46
the InnoDB log file will not necessarily be open while the
server is running, because it can be accessed via memory-mapped I/O.)
If more protection is desired, then the option --external-locking
can be used.
The mandatory advisory lock also fixes intermittent failures of
some crash recovery tests. It turns out that when the mtr test harness
kills and restarts the server, it will not actually ensure that the
old process has terminated before starting the new one.
