Bug #51432 hashmap restore causes crash when endian changes
Submitted: 23 Feb 2010 21:04 Modified: 15 Mar 2010 14:35
Reporter: Andrew Hutchings Email Updates:
Status: Closed Impact on me:
None 
Category:MySQL Cluster: Cluster (NDB) storage engine Severity:S2 (Serious)
Version:7.0 OS:Any
Assigned to: Jonas Oreland CPU Architecture:Any

[23 Feb 2010 21:04] Andrew Hutchings
Description:
Restoring DEFAULT-HASHMAP-240-16 causes cluster failure or error:

Breakpoint 1, BackupRestore::object (this=0x942860, type=24, ptr=0xaeba30)
at restore/consumer_restore.cpp:719
719 if (ret == 0)
(gdb) print ret
$1 = -1
(gdb) print dict->getNdbError()
$2 = (const NdbError &) @0xcc8618: {status = TemporaryError,
classification = InternalTemporary, code = 787, mysql_code = -1,
message = 0x5b274b "Schema transaction aborted", details = 0x0}
(gdb) print old.getName()
$4 = 0xcc9300 "DEFAULT-HASHMAP-240-16"
(gdb) print old.m_impl
$11 = (
NdbHashMapImpl &) @0xbe1040: {<NdbDictionary::HashMap> = {<NdbDictionary::Object> = {_vptr.Object = 0x82cdf0}, m_impl = @0xbe1040}, <NdbDictObjectImpl> = {
m_id = 26, m_version = 1, m_type = HashMap, m_status = New}, m_name = {
m_chr = 0xcc9300 "DEFAULT-HASHMAP-240-16", m_len = 22}, m_map = {
m_items = 0xce4470, m_size = 240, m_incSize = 50, m_arraySize = 260},
m_facade = 0x7fffffff9880}
(gdb) print old.getMapLen()
$13 = 240
(gdb) print old.getObjectId()
$14 = 26
(gdb) print old.getObjectVersion()
$15 = 1
(gdb) print old.getObjectStatus()
$16 = New

perror --ndb 787
NDB error code 787: Schema transaction aborted: Temporary error: Internal temporary

Second restore causes cluster failure.

How to repeat:
.
[23 Feb 2010 21:42] Andrew Hutchings
This is an endianess problem SPARC -> x86
[5 Mar 2010 13:20] Jonas Oreland
proposed patch (untested)

Attachment: bug51432.patch (application/octet-stream, text), 817 bytes.

[5 Mar 2010 13:35] Jonas Oreland
found ctl file at issue,
uploading new (tested) patch
[5 Mar 2010 13:36] Jonas Oreland
new patch this time tested

Attachment: bug51432.patch.v2 (application/octet-stream, text), 821 bytes.

[15 Mar 2010 13:19] Bugs System
A patch for this bug has been committed. After review, it may
be pushed to the relevant source trees for release in the next
version. You can access the patch from:

  http://lists.mysql.com/commits/103234

3449 Jonas Oreland	2010-03-15
      ndb - bug#51432 - handle hashmap wrt endian in backup/restore
[15 Mar 2010 13:22] Bugs System
A patch for this bug has been committed. After review, it may
be pushed to the relevant source trees for release in the next
version. You can access the patch from:

  http://lists.mysql.com/commits/103237

3450 Jonas Oreland	2010-03-15
      ndb - bug#51432 again, took wrong version of patch
[15 Mar 2010 13:26] Jonas Oreland
pushed to 7.0.14 and 7.1.3
[15 Mar 2010 14:35] Jon Stephens
Documented bugfix in the NDB-7.0.14 and 7.1.3 changelogs as follows:

        Restoring a MySQL Cluster backup between platforms having
        different endianness failed when also restoring metadata and the
        backup contained a hashmap not already present in the database
        being restored to. This issue was discovered when trying to
        restore a backup made on Solaris/SPARC to a MySQL Cluster
        running on Solaris/x86, but could conceivably occur in other
        cases where the endianness of the platform on which the backup
        was taken differed from that of the platform being restored to.

Closed.