Commit 214bd5a1 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.

mysys/my_init.c:
  Deinitialize only if initialized already.
sql/log.cc:
  Reset state.
parent 8a41a0ba
......@@ -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