MDEV-29421 Thread (10.6+) and server hangs (10.4/10.5) in 'Opening tables' (on optimized builds) and SIGABRT in safe_mutex_lock (on debug) on I_S read when using Spider
In spider_free_share(), Spider acquires the mutex, spider_open_tables,
and then makes statistics of the target table persistent.
When table_open_cache is small, the statistics persistence can lead to
another call of spider_free_share() and this results in the double
lock on the mutex.
The mutex spider_tbl_mutex is acquired unnecessarily long. Shortening
the locking period resolves the problem.
Fix build without either ENABLED_DEBUG_SYNC or DBUG_OFF
There are separate flags DBUG_OFF for disabling the DBUG facility
and ENABLED_DEBUG_SYNC for enabling the DEBUG_SYNC facility.
Let us allow debug builds without DEBUG_SYNC.
Note: For CMAKE_BUILD_TYPE=Debug, CMakeLists.txt will continue to
define ENABLED_DEBUG_SYNC.
In commit 28325b08633372cc343dfcbc41fe252020cf6e6e
a compile-time option was introduced to disable the macros
DBUG_ENTER and DBUG_RETURN or DBUG_VOID_RETURN.
The parameter name WITH_DBUG_TRACE would hint that it also
covers DBUG_PRINT statements. Let us do that: WITH_DBUG_TRACE=OFF
shall disable DBUG_PRINT() as well.
A few InnoDB recovery tests used to check that some output from
DBUG_PRINT("ib_log", ...) is present. We can live without those checks.
MDEV-28868 : wsrep_incoming_address status variable prints 0 as port number if the port is not mentioned in wsrep_node_incoming_address system variable
Problem was that mysqld_port is not set on set_ports() because
it will be executed later. Fix is naturally fall back to
MYSQL_PORT.
MDEV-29600 Memory leak in row_log_table_apply_update()
row_log_table_apply_update(): Free the pcur.old_rec_buf before returning.
It may be allocated by btr_pcur_store_position() inside
btr_blob_log_check_t::check() and btr_store_big_rec_extern_fields().
This memory leak was introduced in
commit 2e814d4702d71a04388386a9f591d14a35980bfe (MariaDB Server 10.2.2)
via mysql/mysql-server@ce0a1e85e24e48b8171f767b44330da635a6ea0a
(MySQL 5.7.5).
The fix for MDEV-29352 was pushed to 10.6+ but the code causing the
bug is old and the bug is unlikely to be a recent regression in 10.6.
So, we apply the fix also to older versions, 10.3-10.5.
The original commit message:
MDEV-29352 SIGSEGV's in strlen and unknown location on optimized builds at SHUTDOWN
When the UDF creation frails to write the newly created UDF into
the related system table, the UDF is still created in memory.
However, as it is now, the related DLL is unloaded in this case right
in the mysql_create_function. And failure happens when the UDF handle
is freed and tries to unload the respective DLL which is still unloaded.
b9c1c07...
by
Ian Gilfillan <email address hidden>
