The test started failing following the push for BUG#41541.
Some of the algorithms access bytes beyond the input data
and this can affect up to one byte less than "word size"
which is BITS_SAVED / 8. 
      
Fixed by adding (BITS_SAVED / 8) -1 bytes to buffer size
(i.e. Memory Segment #2) to avoid accessing un-allocated data.

myisam/mi_packrec.c:
  Fixed _mi_read_pack_info() method to allocate (BITS_SAVED/8) - 1 
  bytes to the Memory Segment #2
mysql-test/r/myisampack.result:
  Result file for BUG#43973
mysql-test/t/myisampack.test:
  Testcase for BUG#43973

The patch was originally proposed by Mikael and reviewed by Bar.

1. Test case was rewritten completely.
2. Test covers 3 cases:
 a) do deadlock on slave, wait retries of transaction, unlock slave before lock
timeout;
 b) do deadlock on slave and wait error 'lock timeout exceed' on slave;
 c) same as b) but if of max relay log size = 0;
3. Added comments inline.
4. Updated result file.

The problem is that a SELECT .. FOR UPDATE statement might open
a table and later wait for a impeding global read lock without
noticing whether it is holding a table that is being waited upon
the the flush phase of the process that took the global read
lock.

The same problem also affected the following statements:

LOCK TABLES .. WRITE
UPDATE .. SET (update and multi-table update)
TRUNCATE TABLE ..
LOAD DATA ..

The solution is to make the above statements wait for a impending
global read lock before opening the tables. If there is no
impending global read lock, the statement raises a temporary
protection against global read locks and progresses smoothly
towards completion.

Important notice: the patch does not try to address all possible
cases, only those which are common and can be fixed unintrusively
enough for 5.0.

mysql-test/r/lock_multi.result:
  Add test case result for Bug#43230
mysql-test/t/lock_multi.test:
  Add test case for Bug#43230
sql/sql_lex.cc:
  Initialize flag.
sql/sql_lex.h:
  Add a flag to the lexer.
sql/sql_parse.cc:
  Wait for the global read lock is a write lock is going to be
  taken. The wait is done before opening tables.
sql/sql_yacc.yy:
  Protect against the GRL if its a SELECT .. FOR UPDATE or LOCK TABLES
  .. WRITE statement.

Mysql server crashes because unsafe statements warning is wrongly elevated to error,
which is set the error status of Diagnostics_area of the thread in THD::binlog_query().
Yet the caller believes that binary logging shouldn't touch the status, so it will
set the status also later by my_ok(), my_error() or my_message() seperately
according to the execution result of the statement or transaction.
But the status of Diagnostics_area of the thread is allowed to set only once.

Fixed to clear the error wrongly set by binary logging, but keep the warning message.

mysql-test/suite/binlog/r/binlog_stm_ps.result:
  Change unsafe warning to NOTE level
mysql-test/suite/binlog/r/binlog_unsafe.result:
  Test case result for unsafe statements to ensure mysql sever don't crash
mysql-test/suite/binlog/t/binlog_unsafe.test:
  Test case for unsafe statements to ensure mysql sever don't crash
mysql-test/suite/rpl/r/rpl_skip_error.result:
  Change unsafe warning to NOTE level
mysql-test/suite/rpl/r/rpl_stm_loadfile.result:
  Change unsafe warning to NOTE level
mysql-test/suite/rpl/r/rpl_udf.result:
  Change unsafe warning to NOTE level
sql/sql_class.cc:
  the error status of the thread is cleared When a warning is elevated to an error
  because of unsafe warning of binary log.

Fix belonging to bug#42838: Though this bug is only for 6.0 I put in some updated result files for 6.0 and this are the corrsponding resul files for 5.1, so that sys_vars should then run successfully also in 5.1.

Altered the test to accommodate the new behavior of max_allowed_packet.
Had to disconnect / reconnect the default connection for the new value to register.
Re-enabled certain parts of the test that were commented out and added
some setup / cleanup code to ensure proper reset of max_allowed_packet at the end of the test.

Re-recorded the .result file to account for changes to the test.

Bug#32136: mysqld_multi --defaults-file not respected while using \
	--mysqld=mysqld_safe

Revert change that adds "--no-defaults" to mysqld_multi.

This closes Bug#43508 and re-opens Bug#32136.

It was a test case problem: one 'reap' statement was forgotten.

- Link against setargv.obj for wild-card expansion.

- Link against setargv.obj for wild-card expansion.

Original commentary:

Bug #37348: Crash in or immediately after JOIN::make_sum_func_list
            
The optimizer pulls up aggregate functions which should be aggregated in
an outer select. At some point it may substitute such a function for a field
in the temporary table. The setup_copy_fields function doesn't take this
into account and may overrun the copy_field buffer.
            
Fixed by filtering out the fields referenced through the specialized
reference for aggregates (Item_aggregate_ref).
Added an assertion to make sure bugs that cause similar discrepancy 
don't go undetected.


mysql-test/r/func_group.result:
  Backport bug #37348 fix 5.1 --> 5.0.
mysql-test/t/func_group.test:
  Backport bug #37348 fix 5.1 --> 5.0.
sql/item.cc:
  Backport bug #37348 fix 5.1 --> 5.0.
sql/item.h:
  Backport bug #37348 fix 5.1 --> 5.0.
sql/sql_select.cc:
  Backport bug #37348 fix 5.1 --> 5.0.

The problem is that XML functions(items) do not reset null_value
before their execution and further item excution may use
null_value value of the previous result.
The fix is to reset null_value.


mysql-test/r/xml.result:
  test result
mysql-test/t/xml.test:
  test case
sql/item_xmlfunc.cc:
  The problem is that XML functions(items) do not reset null_value
  before their execution and further item excution may use
  null_value value of the previous result.
  The fix is to reset null_value.

Problem: we don't prune a LESS THAN partition if MAXVALUE is given and
given value is equal to a LESS THAN value.

Fix: prune partitions in such cases.


mysql-test/r/partition.result:
  Fix for bug#42944: partition not pruned correctly
    - test result.
mysql-test/t/partition.test:
  Fix for bug#42944: partition not pruned correctly
    - test case.
sql/sql_partition.cc:
  Fix for bug#42944: partition not pruned correctly
    - prune partition if given value is equal to a LESS THAN value
      and it's not a "PARTITION ... LESS THAN MAXVALUE" one.

- Link against setargv.obj for wild-card expansion.