Sys_var_keycache inherits from some variant of Sys_var_integer
Instances of Sys_var_keycache are initialized using the KEYCACHE_VAR macro,
which takes an offset within st_key_cache.
However, the Sys_var_integer CTOR treats the offset as if it was within
global_system_variables (hidden within some layers of macros and fuction
pointers)
The result is that we write arbitrary data to arbitrary locations in memory.
This all happens during static initialization of global objects,
i.e. before we have even entered the main() function.
Bug#12325449 TYPO IN CMAKE/DTRACE.CMAKE
Fix typo in dtrace.cmake
Problem : The build might fail with
make[2]: *** No rule to make target `../sql/z',
needed by `sql/mysqld_dtrace_all.o'. Stop.
if one of plugins would depends on system libz
library
Fix: Filter out non-static dependent libraries
when dtracing static libs
On Solaris with version 3.4.6, the ha_example.so shared library is built
with DTrace and the server is built without DTrace support. This occurs
because dtrace.cmake disables DTrace support for 3.4.6, but still set
HAVE_DTRACE, which causes probes_mysql.h to include probes_mysql_dtrace.h
instead of probes_mysql_nodtrace.h.
This patch fixes this by not setting HAVE_DTRACE on Solaris for GCC 3.4.6.
Crash happens in dlopen() code when trying to load the library. Crash does not happen when library is
not DTrace instrumented . Additionally, crash does not happen with default Solaris 10 GCC 3.4.3 and
it does not happen if main executable is instrumented.
So , just check for this specific situation (32 bit, GCC3.4.6 , Solaris) and disable Dtrace in shared libraries.
We have only single plugin so far that is instrumented (ha_example)
fix excessive relinking that results from rerunning
dtrace -G second time on the objects that come into
static library.
The reason for relinking is that dtrace -G changes
timestamp for the object file, which in turn results
in re-archiving the mysys on next time make runs,
which causes relinking of the whole mysql, because
everything depends on mysys.
The fix is to copy objects into temp before running
dtrace -G in mysqld pre-build step. This way dtrace
does not affect the object timestamp.
Rerun dtrace -G on all objects that can contan dtrace probes (also objects that are
part of static libs) before linking mysqld to produce dtrace_probes_all.o and link
dtrace_probes_all.o with mysqld
This ugly workaround was inspired by handling dtrace using autotools.
