Commit 064c1b2c authored by Davi Arnaut's avatar Davi Arnaut

Bug#43706: libmysqld segfaults when re-intialised

Bug#44091: libmysqld gets stuck waiting on mutex on initialization

The problem was that libmysqld wasn't enforcing a certain
initialization and deinitialization order for the mysys
library. Another problem was that the global object used
for management of log event handlers (aka LOGGER) wasn't
being prepared for a possible reutilization.

What leads to the hang/crash reported is that a failure
to load the language file triggers a double call of the
cleanup functions, causing an already destroyed mutex to
be used.

The solution is enforce a order on the initialization and
deinitialization of the mysys library within the libmysqld
library and to ensure that the global LOGGER object reset
it's internal state during cleanup.
parent 49ab0497
......@@ -136,6 +136,10 @@ void my_end(int infoflag)
*/
FILE *info_file= DBUG_FILE;
my_bool print_info= (info_file != stderr);
if (!my_init_done)
return;
/*
We do not use DBUG_ENTER here, as after cleanup DBUG is no longer
operational, so we cannot use DBUG_RETURN.
......
......@@ -845,6 +845,7 @@ void LOGGER::cleanup_base()
{
table_log_handler->cleanup();
delete table_log_handler;
table_log_handler= NULL;
}
if (file_log_handler)
file_log_handler->cleanup();
......@@ -855,7 +856,11 @@ void LOGGER::cleanup_end()
{
DBUG_ASSERT(inited == 1);
if (file_log_handler)
{
delete file_log_handler;
file_log_handler=NULL;
}
inited= 0;
}
......
Markdown is supported
0%
or
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment