Problem Description And Fix:
Inserting a fudged record in mysql.proc with the dbname
column value as test and the name column as empty, will
cause a crash in mysqld when we run the command DROP
DATABASE test.
During DROP DATABASE test, mysql_rm_db subsequently
calls lock_db_routines. In the routine we fetch the
field 'name' from mysql.proc by calling the underlying
storage engine API in lock_db_routines. This cause NULL
value as the field column of mysql.proc and subsequent
dereference MDL_request::init leads to crash.
Modifying mysql.proc using SQL command by user is not
supported, but in principle, there is a possibility
of mysql.proc getting corrupted which can also lead
to empty fields and arbitary values. The patch fixes
the crash by checking NULL and propagating the appopriate
error code to the user.
Rename a CMake variable in compile_flags.cmake to avoid triggering
CMake 3.1 warning about CMP0054 about interpreting if() arguments
as keywords or variables.
No changes in behavior.
special character sets like utf16, utf32, ucs2.
Analysis: MySQL server does not support few special character sets like
utf16,utf32 and ucs2 as "client's character set"(eg: utf16,utf32, ucs2).
It is known limitation listed in the documentation
http://dev.mysql.com/doc/refman/5.5/en/charset-connection.html.
The default value for default-character-set parameter is 'auto'
which means that if the server's character set is not supported,
then server automatically changes client's character set to
predefined character-set which is 'latin1' in the current code.
Eg:
$ ./mysql -uroot -S$SOCKET_FILE --default-character-set=utf16
ERROR 1231 (42000): Variable 'character_set_client' can't be set to the value of 'utf16'
$ ./mysql -uroot -S$SOCKET_FILE will be successfully connected to
server with 'latin1' as default client side character set.
When IO thread is trying to connect to Master, it sets server's character
set as client's character set. When Slave server is started with these
special character sets, IO thread (which is like a connection to Master)
fails because of the above said limitation.
Fix: Now even IO thread also behaves the same as a regular client behaves.
i.e., If server's character set is not supported as client's character set,
then set default's client character set(latin1) as client's character set.
Attempt to truncate temporary table using Blackhole storage and
locked by LOCK TABLES caused assertion failure and crashes.
Blackhole is a transaction-aware engine. While creating the temporary
table in transaction-aware engine, temporary table of type
"TRANSACTIONAL_TMP_TABLE" is created. For such temporary tables
a THR_LOCK lock is acquired by the LOCK TABLE operation. References
to them are also added into MYSQL_LOCK::table[] array. Also for
Blackhole engine, flag HTON_CAN_RECREATE is set.
While truncating temporary tables, no locks are taken and
recreate_temporary_table() is called for engines having
"HTON_CAN_RECREATE" in flag.
Function closefrm() is called from the recreate_temporary_table(),
to close the current temporary table. In closefrm(), the lock on
table expected is "F_UNLCK". In debug builds, assert condition on
this fails when lock of type "F_WRLCK" is acquired by LOCK TABLE
operation on temporary tables using Blackhole engine.
In non-debug builds closefrm() simply freed TABLE object leaving
dangling pointer to this object in MYSQL_LOCK::table[] array which
might lead to crashes later.
Fix:
---------
To fix this issue, we now unlock and remove table from MYSQL_LOCK::table[]
array before calling close_temporary_table() in recreate_temporary_table().
This is achieved by calling mysql_lock_remove() function for this table.
The test case tried to trigger a DEBUG_SYNC point at the end of a SELECT
SLEEP(5) statement. It did this by using EXECUTE 2, intending to trigger first
at the end of SET DEBUG_SYNC, and second at the end of the SELECT SLEEP(5).
However, in --ps-protocol mode, this does not work, because the SELECT is
executed in two steps (Prepare followed by Execute). Thus, the DEBUG_SYNC got
triggered too early, during the Prepare stage rather than Execute, and the
test case could race and information_schema.processlist see the thread in the
wrong state.
This patch fixes by changing the way the DEBUG_SYNC point is triggered. Now we
add a DBUG injection inside the code for SLEEP(5). This ensures that the
DEBUG_SYNC point is not activated until the SLEEP(5) is running, ensuring
that the following wait for completion will be effective.
Fix:
===
Backport Bug#11756194 to mysql-5.5. slave breaks if
'drop database' fails on master and mismatched tables on
slave.
'DROP TABLE <deleted tables>' was binlogged when
'DROP DATABASE' failed and at least one table was deleted
from the database. The log event would lead slave SQL thread
stop if some of the tables did not exist on slave.
After this patch, It is always binlogged with 'IF EXISTS'
option.
CRASHES ON EVERY START ATTEMPT
Description:
------------
push_warning_printf function is used to print the warning message
to the client. So this function should not invoke while recovering
the server. Moreover current_thd is NULL while starting the server.
Solution:
---------
- Avoiding the warning to be printed while recovery.
This patch already pushed in mysql-5.6.
