Problem: ucs2 was correctly disallowed in "SET NAMES" only,
while mysql_real_connect() and mysql_change_user() still allowed
to use ucs2, which made server crash.

Fix: disallow ucs2 in mysql_real_connect() and mysql_change_user().

  @ sql/set_var.cc
    Using new function.

  @ sql/sql_acl.cc
    - Return error if character set initialization failed
    - Getting rid of pointer aliasing:
      Initialize user_name to NULL, to avoid double free().

  @ sql/sql_connect.cc
    - in case of unsupported client character set send error and return true
    - in case of success return false

  @ sql/sql_connect.h
    - changing return type for thd_init_client_charset() to bool,
      to return errors to the caller

  @ sql/sql_parse.h
    - introducing a new function, to reuse in all places where we need
    to check client character set.

  @ tests/mysql_client_test.c
    Adding test

      
Problem:
  IF() did not copy collation derivation and repertoire from
  an argument if the opposite argument was NULL:
    IF(cond, res1, NULL)
    IF(cond, NULL, res2)
  only CHARSET_INFO pointer was copied.
  This resulted in illegal mix of collations error.

Fix:
  copy all collation parameters from the non-NULL argument:
  CHARSET_INFO pointer, derivation, repertoire.

          memory reference

There are two issues present here.
  1) There is a possibility that we test a byte beyond the
     allocated buffer

  2) We compare a byte that might never have been
     initalized to see if it's 0.

The first issue is not triggered by existing code, but an
ASSERT has been added to safe-guard against introducing
new code that triggers it.

The second issue is what triggers the Valgrind warnings
reported in the bug report. A buffer is allocated in
class String to hold the value. This buffer is populated
by the character data constituting the string, but is not
zero-terminated in most cases.  Testing if it is indeed
zero-terminated means that we check a byte that has never
been explicitly set, thus causing Valgrind to trigger.

Note that issue 2 is not a serious problem.  The variable
is read, and if it's not zero, we will set it to zero.
There are no further consequences.

Note that this patch does not fix the underlying problems
with issue 1, as it is deemed too risky to fix at this
point (as noted in the bug report).  As discussed in
the report, the c_ptr() method should probably be
replaced, but this requires a thorough analysis of the
~200 calls to the method.

With --mem if fails with
+UNEXPECTED ERROR NUMBER: 1290

In var/log/mysqld.2.err we have:
[ERROR] LOAD DATA INFILE in the slave SQL Thread can only read from --slave-load-tmpdir. Please, report a bug.
[ERROR] Slave SQL: Error 'The MySQL server is running with the --slave-load-tmpdir option so it cannot execute this statement' on query. Default database: 'test'. Query: 'LOAD DATA INFILE '../../tmp/SQL_LOAD-2-1-1.data' INTO  TABLE `t1` FIELDS TERMINATED BY '\t' ENCLOSED BY '' ESCAPED BY '\\' LINES TERMINATED BY '\n' (`a`, `b`)', Error_code: 1290

getcwd() in the server yields something like: /dev/shm/var_auto_iv5Q/mysqld.2/data

No conflicts

Assertion `bitmap_is_set_all(&table->s->all_set)' failed in
handler::ha_reset

This followup fixes the compilation warning
  'test_bit' may be used uninitialized in this function
introduced by the previous patch.

Removes SHOW NEW MASTER statement and all related code.
Also removes the unused function update_slave_list from repl_failsafe.cc.

Text conflict in include/my_bit.h
Text conflict in include/my_bitmap.h
Text conflict in mysys/my_bitmap.c

Assertion `bitmap_is_set_all(&table->s->all_set)' failed in
handler::ha_reset

This assertion could be triggered if two connections simultaneously
executed two bitmap test functions on the same bitmap. For example,
the assertion could be triggered if one connection executed UPDATE
while a second connection executed SELECT on the same table.

Even if bitmap test functions have read-only semantics and have
const bitmaps as parameter, several of them modified the internal
state of the bitmap. With interleaved execution of two such functions
it was possible for one function to modify the state of the same
bitmap that the other function had just modified. This lead to an
inconsistent state and could trigger the assert.

Internally the bitmap uses 32 bit words for storage. Since bitmaps
can contain any number of bits, the last word in the bitmap may
not be fully used. A 32 bit mask is maintained where a bit is set
if the corresponding bit in the last bitmap word is unused.
The problem was that several test functions applied this mask to
the last word. Sometimes the mask was negated and used to zero out
the remainder of the last word and sometimes the mask was used as-is
to fill the remainder of the last word with 1's. This meant that if
a function first used the negated mask and another function then
used the mask as-is (or vice-versa), the first function would then
get the wrong result.

This patch fixes the problem by changing the implementation of
9 bitmap functions that modified the bitmap state even if the 
bitmap was declared const. These functions now preserve the
internal state of the bitmap. This makes it possible for
two connections to concurrently execute two of these functions
on the same bitmap without issues.

The patch also removes dead testing code from my_bitmap.c.
These tests have already been moved to unittest/mysys/bitmap-t.c.
Existing test coverage of my_bitmap has been extended.

No MTR test case added as this would require adding several sync
points to the bitmap functions. The patch has been tested with
a non-deterministic test case posted on the bug report.

post-push fix: make it work in out-of-source builds.

fix for bug @59888.

create spatial index on char > 31 bytes". Did after-merge
fixes.

  
Backporting the patch from BUG#11753506 into mysql-5.5 
as it is already in mysql-trunk but not in mysql-5.5.

Backporting the patch from BUG#11753489 into mysql-5.5 
as it is already in mysql-trunk but not in mysql-5.5.

attempt to create spatial index on char > 31 bytes".

Attempt to create spatial index on char field with length
greater than 31 byte led to assertion failure on server
compiled with safemutex support.

The problem occurred in mi_create() function which was called
to create a new version of table being altered. This function
failed since it detected an attempt to create a spatial key
on non-binary column and tried to return an error.
On its error path it tried to unlock THR_LOCK_myisam mutex
which has not been not locked at this point. Indeed such an
incorrect behavior was caught by safemutex wrapper and caused
assertion failure.

This patch fixes the problem by ensuring that mi_create()
doesn't releases THR_LOCK_myisam mutex on error path if it was
not acquired.

rw_lock_create_func(): Initialize lock->writer_thread, so that Valgrind
will not complain even when Valgrind instrumentation is not enabled.
Flag lock->writer_thread uninitialized, so that Valgrind can complain
when it is used uninitialized.

rw_lock_set_writer_id_and_recursion_flag(): Revert the bogus Valgrind
instrumentation that was pushed in the first attempt to fix this bug.

Assert in Diagnostics_area::set_ok_status() for XA COMMIT

This assert was triggered if XA COMMIT was issued when an XA transaction
already had encountered an error (e.g. a deadlock) which required
the XA transaction to be rolled back.

In general, the assert is triggered if a statement tries to send OK to
the client when an error has already been reported. It was triggered
in this case because the trans_xa_commit() function first reported an
error, then rolled back the transaction and finally returned FALSE,
indicating success. Since trans_xa_commit() reported success,
mysql_execute_command() tried to report OK, triggering the assert.

This patch fixes the problem by fixing trans_xa_commit() to return TRUE
if it encounters an error that requires rollback, even if the rollback
itself is successful.

Test case added to xa.test.