BUG#13431369 - MAIN.VARIABLES-NOTEMBEDDED CRASHES THE SERVER SPORADICALLY ON WINDOWS

On shutdown(), Windows can drop traffic still queued for sending even if that
wasn't specifically requested. As a result, fatal errors (those after
signaling which the server will drop the connection) were sometimes only
seen as "connection lost" on the client side, because the server-side
shutdown() erraneously discarded the correct error message before sending
it.

If on Windows, we now use the Windows API to access the (non-broken) equivalent
of shutdown().

Backport from trunk
BUG#13431369 - MAIN.VARIABLES-NOTEMBEDDED CRASHES THE SERVER SPORADICALLY ON WINDOWS

On shutdown(), Windows can drop traffic still queued for sending even if that
wasn't specifically requested. As a result, fatal errors (those after
signaling which the server will drop the connection) were sometimes only
seen as "connection lost" on the client side, because the server-side
shutdown() erraneously discarded the correct error message before sending
it.

If on Windows, we now use the Windows API to access the (non-broken) equivalent
of shutdown().

Backport from trunk
BUG#13431369 - MAIN.VARIABLES-NOTEMBEDDED CRASHES THE SERVER SPORADICALLY ON WINDOWS

On shutdown(), Windows can drop traffic still queued for sending even if that
wasn't specifically requested. As a result, fatal errors (those after
signaling which the server will drop the connection) were sometimes only
seen as "connection lost" on the client side, because the server-side
shutdown() erraneously discarded the correct error message before sending
it.

If on Windows, we now use the Windows API to access the (non-broken) equivalent
of shutdown().

Backport from trunk
auto merge
Raise version number after cloning 5.0.96
cloning 5.5.22
Raise version number after cloning 5.1.62
merge 5.0-security->5.1-security
merge mysql-5.1-security->mysql-5.5-security
Bug#13519724 63793: CRASH IN DTCOLLATION::SET(DTCOLLATION &SET)

Backport of fix for:
Bug#53236 Segfault in DTCollation::set(DTCollation&)
Merge 5.1-security => 5.5-security
auto-merge
auto-merge
auto-merge
Bug#13693012: SLAVE CRASHING ON INSERT STATEMENT WITH MERGE TABLE 

PROBLEM: After WL 4144, when using MyISAM Merge tables, the routine
open_and_lock_tables will append to the list of tables to lock, the
base tables that make up the MERGE table. This has two side-effects in
replication: 

  1. On the master side, we log additional table maps for the base
     tables, since they appear in the list of locked tables, even
     though we don't really use them at the slave.

  2. On the slave side, when opening a MERGE table while applying a
     ROW event, additional tables are appended to the list of tables
     to lock.

Side-effect #1 is not harmful. It's just that when using MyISAM Merge
tables a few table maps more may be logged.

Side-effect #2, is harmful, because the list rli->tables_to_lock is an
extended structure from TABLE_LIST in which the extra fields are
filled from the table maps that are processed. Since
open_and_lock_tables appends tables to the list after all table map
events have been processed we end up with entries without
replication/table map data on them. Thus when trying to access that
info for these extra tables, the server will crash.

SOLUTION: We fix side-effect #2 by making sure that we access the
replication part of the structure for those in the list that were
accounted for when processing the correspondent table map events. All
in all, we never go beyond rli->tables_to_lock_count.

We also deploy an assertion when clearing rli->tables_to_lock, making
sure that the base tables are not in the list anymore (were closed in
close_thread_tables).
BUG#13693012

Automerged approved cset.
Bug#13635833: MULTIPLE CRASHES IN FOREIGN KEY CODE WITH CONCURRENT DDL/DML
      
There are two threads.  In one thread, dml operation is going on 
involving cascaded update operation.  In another thread, alter 
table add foreign key constraint is happening.  Under these 
circumstances, it is possible for the dml thread to access a 
dict_foreign_t object that has been freed by the ddl thread.  
The debug sync test case provides the sequence of operations.  
Without fix, the test case will crash the server (because of 
newly added assert).  With fix, the alter table stmt will return 
an error message.  
      
rb:947
approved by Jimmy Yang
Bug#13635833: MULTIPLE CRASHES IN FOREIGN KEY CODE WITH CONCURRENT DDL/DML
      
There are two threads.  In one thread, dml operation is going on 
involving cascaded update operation.  In another thread, alter 
table add foreign key constraint is happening.  Under these 
circumstances, it is possible for the dml thread to access a 
dict_foreign_t object that has been freed by the ddl thread.  
The debug sync test case provides the sequence of operations.  
Without fix, the test case will crash the server (because of 
newly added assert).  With fix, the alter table stmt will return 
an error message.  
      
Backporting the fix from MySQL 5.5 to 5.1

rb:961
rb:947
Null merge from mysql-5.1 to mysql-5.5
The innodb plugin module cannot use DEBUG_SYNC_C facility on Windows. 
Taking care of it.