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.

Portions of this website are copyright © 2001, 2002 The PHP Group

Page generated in 0.066 sec. using MySQL 8.4.7-u6-cloud

Timestamp references displayed by the system are UTC.
Content reproduced on this site is the property of the respective copyright holders.
It is not reviewed in advance by Oracle and does not necessarily represent the opinion of Oracle or any other party.