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
--BZR--
revision-id: tatjana.nuernberg@oracle.com-20120217190217-xfd9tdi9rlikkoqv
property-branch-nick: mysql-5.1-security
property-file-info: ld7:file_id62:sp1f-violite.h-19700101030959-jfyqeh5pmto4ncgcdcdf36bl5ininiqx7:message64:export mysql_socket_shutdown(). It lives in vio in the backport.4:path17:include/violite.hed7:file_id62:sp1f-mysqld.cc-19700101030959-zpswdvekpvixxzxf7gdtofzel7nywtfj7:message68:Go through our own shutdown() rather than straight to the POSIX one.4:path13:sql/mysqld.cced7:file_id63:sp1f-viotcpip.c-20010520120437-u3pbzbt3fdfbclbmusalnzmuqh2y4nav7:message140:Define mysql_socket_shutdown(). On UNIXoid systems, it's just a wrapper for shutdown(), but
property-file-info: on Window, it uses DisconnectEx, which is magic.4:path15:vio/viosocket.cee
testament3-sha1: 55015b9f9dbabeeb2d2ac2e02af7c6405acc8f4d
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


--BZR--
revision-id: tatjana.nuernberg@oracle.com-20120219085711-pmxlf1ma8kf3n3os
property-branch-nick: 51-13431369
testament3-sha1: 4584179ccb268c02e869c1ecc9ea2a0a6b464015
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

--BZR--
revision-id: tatjana.nuernberg@oracle.com-20120219090052-cf5fy7fklsovj04j
property-branch-nick: 55-13431369
testament3-sha1: eafa26beb23ed25d3bf7792784a2fccc311cd67f
auto merge
--BZR--
revision-id: tatjana.nuernberg@oracle.com-20120219090944-uxkkkpvovv3xaabv
property-branch-nick: 55-13431369
testament3-sha1: 419c6bdfeca249d3f217d7b1060b1269b717e6e8
Raise version number after cloning 5.0.96
--BZR--
revision-id: sunanda.menon@oracle.com-20120220051912-e3ty0t6r13kv587n
property-branch-nick: mysql-5.0-security
testament3-sha1: a68d52bbb7fe78b46202d7a1b3d60a26f1b5b019
cloning 5.5.22

--BZR--
revision-id: hery.ramilison@oracle.com-20120220155454-qyf9zf0iuzs1fbtr
property-branch-nick: mysql-5.5-security
testament3-sha1: 1f89bd7e3631af6100589d039833cde08a40c8c5
Raise version number after cloning 5.1.62
--BZR--
revision-id: karen.langford@oracle.com-20120220160324-zmv0y01iwkz9zikp
property-branch-nick: mysql-5.1-security
testament3-sha1: aacea7327d386b54fccfe4af6420ce2f03f63387
merge 5.0-security->5.1-security

--BZR--
revision-id: georgi.kodinov@oracle.com-20120221090608-pew90yeuex9a556b
property-branch-nick: mysql-5.1-security
testament3-sha1: a4abbf16d97bb819fe06a6e64287bfe082f32560
merge mysql-5.1-security->mysql-5.5-security

--BZR--
revision-id: georgi.kodinov@oracle.com-20120221090912-0gx0f6yjvsh6bdr9
property-branch-nick: mysql-5.5-security
testament3-sha1: 13fb6ba00d4aa960bc44d0319ffe94092e62cb73
Bug#13519724 63793: CRASH IN DTCOLLATION::SET(DTCOLLATION &SET)

Backport of fix for:
Bug#53236 Segfault in DTCollation::set(DTCollation&)

--BZR--
revision-id: tor.didriksen@oracle.com-20120222101750-sqigipq3q9xwerlp
property-branch-nick: 5.1-security
testament3-sha1: 9968c79a7ba9803308cfacdeb64c3c772bb84ca9
Merge 5.1-security => 5.5-security
--BZR--
revision-id: tor.didriksen@oracle.com-20120222102052-ek6yt0t2ewj1cool
property-branch-nick: 5.5-security
testament3-sha1: 479b373c512f9cd67be69fe695959e6ace71e8f0
auto-merge
--BZR--
revision-id: tatjana.nuernberg@oracle.com-20120222151812-e5augtq1i8tl5mw4
property-branch-nick: 51-13431369pb
testament3-sha1: a459bd7c90216e44e77c5c36fbe1aa409e640418
auto-merge
--BZR--
revision-id: tatjana.nuernberg@oracle.com-20120222153024-puz3791p60k5sgg1
property-branch-nick: 55-13431369pb
testament3-sha1: 9a00b49bcfca61b8558e27aae13dd597272db6c1
auto-merge
--BZR--
revision-id: tatjana.nuernberg@oracle.com-20120222153307-k6avkjdjo00pp4j3
property-branch-nick: 55-13431369pb
testament3-sha1: 6225d3a310f7e8bdf0a542d6db60ed7e0122efb2
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).
--BZR--
revision-id: luis.soares@oracle.com-20120224160743-pt2iw2esti6vvv47
property-branch-nick: mysql-5.5-security
testament3-sha1: 6763d0e86d59a679bdc27ac25a99b6014fb5c080
BUG#13693012

Automerged approved cset.
--BZR--
revision-id: luis.soares@oracle.com-20120224163246-hb3633lzuetzp4mk
property-branch-nick: mysql-5.5-security
testament3-sha1: c09a18b7d35db6e9b10ca7c85dc3c32be66d78f1
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
--BZR--
revision-id: annamalai.gurusami@oracle.com-20120227115356-znid62pz6ohj6z5m
property-branch-nick: mysql-5.5-security-bug13635833
testament3-sha1: 202bed57bd343898e1b39c552a13315894202f9d
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

--BZR--
revision-id: annamalai.gurusami@oracle.com-20120301053551-ep3d97bdnadh5t0o
property-branch-nick: mysql-5.1-security-bug13635833
testament3-sha1: 9a30240568eda7b35c40d67ea159151ddcfc0dab
Null merge from mysql-5.1 to mysql-5.5
--BZR--
revision-id: annamalai.gurusami@oracle.com-20120301082743-edao9ex1uishqp7v
property-branch-nick: mysql-5.5-security-bug13635833
testament3-sha1: f791e6d33d9c65abd1bc48992edc863a3692e188
The innodb plugin module cannot use DEBUG_SYNC_C facility on Windows. 
Taking care of it.  
--BZR--
revision-id: annamalai.gurusami@oracle.com-20120301101423-b52mg7zngg4jm1rh
property-branch-nick: mysql-5.1-security-bug13635833
testament3-sha1: b5983cd18de6289035869fab949e1e2c2d46436d