NOTE: Backporting the patch to next-mr.

WL#4828 Augment DBUG_ENTER/DBUG_EXIT to crash MySQL in different functions
-------

The assessment of the replication code in the presence of faults is extremely
import to increase reliability. In particular, one needs to know if servers
will either correctly recovery or print out appropriate error messages thus
avoiding unexpected problems in a production environment.

In order to accomplish this, the current patch refactories the debug macros
already provided in the source code and introduces three new macros that
allows to inject faults, specifically crashes, while entering or exiting a
function or method. For instance, to crash a server while returning from
the init_slave function (see module sql/slave.cc), one needs to do what
follows:

1 - Modify the source replacing DBUG_RETURN by DBUG_CRASH_RETURN;

  DBUG_CRASH_RETURN(0);

2 - Use the debug variable to activate dbug instructions:

  SET SESSION debug="+d,init_slave_crash_return";

The new macros are briefly described below:

DBUG_CRASH_ENTER (function) is equivalent to DBUG_ENTER which registers the
beginning of a function but in addition to it allows for crashing the server
while entering the function if the appropriate dbug instruction is activate.
In this case, the dbug instruction should be "+d,function_crash_enter".

DBUG_CRASH_RETURN (value) is equivalent to DBUG_RETURN which notifies the
end of a function but in addition to it allows for crashing the server
while returning from the function if the appropriate dbug instruction is
activate. In this case, the dbug instruction should be
"+d,function_crash_return". Note that "function" should be the same string
used by either the DBUG_ENTER or DBUG_CRASH_ENTER.

DBUG_CRASH_VOID_RETURN (value) is equivalent to DBUG_VOID_RETURN which
notifies the end of a function but in addition to it allows for crashing
the server while returning from the function if the appropriate dbug
instruction is activate. In this case, the dbug instruction should be
"+d,function_crash_return". Note that "function" should be the same string
used by either the DBUG_ENTER or DBUG_CRASH_ENTER.

To inject other faults, for instance, wrong return values, one should rely
on the macros already available. The current patch also removes a set of
macros that were either not being used or were redundant as other macros
could be used to provide the same feature. In the future, we also consider
dynamic instrumentation of the code.


BUG#45747 DBUG_CRASH_* is not setting the strict option
---------
      
When combining DBUG_CRASH_* with "--debug=d:t:i:A,file" the server crashes
due to a call to the abort function in the DBUG_CRASH_* macro althought the
appropriate keyword has not been set.

NOTE: Backporting the patch to next-mr.
            
The use of option log_slave_updates without log_bin was preventing the server
from starting. To fix the problem, we replaced the error message and the exit
call by a warning message.

files

NOTE: this is the backport to next-mr.
            
SHOW BINLOG EVENTS does not work with relay log files. If issuing
"SHOW BINLOG EVENTS IN 'relay-log.000001'" in a non-empty relay
log file (relay-log.000001), mysql reports empty set.
            
This patch addresses this issue by extending the SHOW command
with RELAYLOG. Events in relay log files can now be inspected by
issuing SHOW RELAYLOG EVENTS [IN 'log_name'] [FROM pos] [LIMIT
[offset,] row_count].

when WL#2867 or associated fixes for 5.1 is added to solve the problem.

There is a missing check for memory allocation failure when allocating
memory for the handlerton structure. If the handlerton init function
tries to de-reference the pointer, it will cause a segmentation fault
and crash the server.

This patch fixes the problem by not calling the init function if memory
allocation failed, and instead prints an informative error message and
reports the error to the caller.

            
Adding header include file guards to files that are missing such.

When setting AUTOCOMMIT=1 after starting a transaction, the binary log
did not commit the outstanding transaction. The reason was that the binary
log commit function saw the values of the new settings, deciding that there
were nothing to commit.

Fixed the problem by moving the implicit commit to before the thread option
flags were changed, so that the binary log sees the old values of the flags
instead of the values they will take after the statement.

slave leaves slave unstable

Problem: when replicating from non-transactional to
transactional engine with autocommit off, no BEGIN/COMMIT
is written to the binlog. When the slave replicates, it
will start a transaction that never ends.

Fix: Force autocommit=on on slave by always replicating
autocommit=1 from the master.

Extract substr into local variable

with the newer pb2 testing environments

a "if"
Bug #41913 mysqltest cannot source files from if inside while
Some commands require additional processing which only works first time
Keep content for write_file or append_file with the st_command struct
Add tests for those cases to mysqltest.test

This fixes the regression introduced in 5.1 that prevents 64 bit builds on Intel while still keeping the core2 hack operational so the cluster can build.

Remove a self assignment.
Rework a few constructs to avoid a potential overflow.

Based upon patch contributed by Michal Hrusecky

On 64-bits machines the calculation gets the wrong types and results
in very large numbers. Fixed by explicitly cast month to (int)