Commit c1e2b147 authored by He Zhenxing's avatar He Zhenxing

Backport BUG#41013 main.bootstrap coredumps in 6.0-rpl

When a storage engine failed to initialize before allocated slot number,
the slot number would be 0, and when later finalizing this plugin, it would
accidentally unplug the storage engine currently uses slot 0.

This patch fixed this problem by add a new macro value HA_SLOT_UNDEF to
distinguish undefined slot number from slot 0.
parent 6d1ad124
......@@ -413,7 +413,13 @@ int ha_finalize_handlerton(st_plugin_int *plugin)
reuse an array slot. Otherwise the number of uninstall/install
cycles would be limited.
*/
if (hton->slot != HA_SLOT_UNDEF)
{
/* Make sure we are not unpluging another plugin */
DBUG_ASSERT(hton2plugin[hton->slot] == plugin);
DBUG_ASSERT(hton->slot < MAX_HA);
hton2plugin[hton->slot]= NULL;
}
my_free((uchar*)hton, MYF(0));
......@@ -438,6 +444,7 @@ int ha_initialize_handlerton(st_plugin_int *plugin)
goto err_no_hton_memory;
}
hton->slot= HA_SLOT_UNDEF;
/* Historical Requirement */
plugin->data= hton; // shortcut for the future
if (plugin->plugin->init && plugin->plugin->init(hton))
......
......@@ -216,6 +216,13 @@
*/
#define MAX_HA 15
/*
Use this instead of 0 as the initial value for the slot number of
handlerton, so that we can distinguish uninitialized slot number
from slot 0.
*/
#define HA_SLOT_UNDEF ((uint)-1)
/*
Parameters for open() (in register form->filestat)
HA_GET_INFO does an implicit HA_ABORT_IF_LOCKED
......
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