Revert "BUG#27531186: BUG#89624: Ensure that we search the right path…

…s for ndb_mgm binary"

BUG#26236857 - LRU_GET: ASSERTION `!IS_BUSY_MACHINE(&RETVAL->PAX)' FA…

…ILED (Post-Fix)

This patch maintains the removal of the assertion code, but reverts the part of the
patch that changes they way log_start is sent to other members and how new
incarnations nodes are seen by the system within XCom.

(cherry picked from commit 00d87720eecd2a411b7930574fc3b5c05296e651)

Bug#27675005 NDB::DROPEVENTOPERATION() CAUSED CRASH, - GCC CODE GEN. …

…BUG?

When Ndb::DropEventOperation() decided to clean up any pending event,
it failed to correctly clear the 'tail' pointer to the list of 'Gci_ops'
being deleted and discarded. Thus the 'tail' pointer refers a deleted
Gci_ops object.

Later arriving Gci_ops may then be inserted as 'next' Gci_ops
to this deleted object, causing memory corription and other havoc.

Root cause is that we explicitely called the EventBufData_list d'tor
from NdbEventBuffer::free_list() as a convinient way of releasing any
Gci_op / Gci_ops in the 'list'. This d'tor also updated the head and
tail pointer of the list as each contained element is deleted.

However, with the (new) 'dead storage elimination'-optimization
introduced in gcc 6.0, the updated 'head' and 'tail' in the destructed
'list' is not considered persistent after the destruction, thus
the code is eliminated by the optimizer.

This patch replace the explicit call to the d'tor by calling the
new method ::delete_gci_ops(). This methods essentially does the
same as the d'tor, which now is also changed to call this method.
Not calling the d'tor, disalowes the compiler to do dse-optimization
of the cleared head / tail pointer, which removes the root cause.

Also introduce a Gci_ops d'tor which takes over delete[] of
Gci_op contained within it. This replace part of the
'delete' code from delete_next_gci_ops()

(cherry picked from commit f22bdc5f0be4145f352527c7b4124a6d434a4678)

Merge branch 'mysql-5.5-cluster-7.2' into mysql-5.6-cluster-7.3

Bug #27461752 NDB-API, INDEXSCANOPERATION, INCORRECT RESULT WHEN NULL…

…-BOUND IS SPECIFIED

Code generated for NdbIndexScanOperation::setBoundHelperOldApi() failed to set
the 'nullBit' mask correctly if a NULL value was specified for the 'bound'.

Was caused by 'delete-null-pointer-checks' optimization in gcc compiler,
in combination with memcpy() having the 'nonnull' property set for its two
pointer arguments. Thus it assumed that 'aValue != NULL' and eliminated
later code checking for 'aValue == NULL'

(cherry picked from commit e0a930454239e447e44c0ed9b0294e6ac3e05f75)

BUG#26236857 - LRU_GET: ASSERTION `!IS_BUSY_MACHINE(&RETVAL->PAX)' FA…

…ILED (Post-Fix)

This patch maintains the removal of the assertion code, but reverts the part of the
patch that changes they way log_start is sent to other members and how new
incarnations nodes are seen by the system within XCom.

(cherry picked from commit 00d87720eecd2a411b7930574fc3b5c05296e651)

Merge branch 'mysql-5.5' into mysql-5.6

BUG#27216817: INNODB: FAILING ASSERTION:

              PREBUILT->TABLE->N_MYSQL_HANDLES_OPENED == 1

ANALYSIS:
=========

Adding unique index to a InnoDB table which is locked as
mutliple instances may trigger an InnoDB assert.

When we add a primary key or an unique index, we need to
drop the original table and rebuild all indexes. InnoDB
expects that only the instance of the table that is being
rebuilt, is open during the process. In the current
scenario we have opened multiple instances of the table.
This triggers an assert during table rebuild.
'Locked_tables_list' encapsulates a list of all
instances of tables locked by LOCK TABLES statement.

FIX:
===
We are now temporarily closing all the instances of the
table except the one which is being altered and later
reopen them via Locked_tables_list::reopen_tables().

Merge branch 'mysql-5.6' into mysql-5.7

(cherry picked from commit 26429d55448d54c7e0ecf070956e48fdcfca603a)