MySQL Bugs: #54487: Wrong data inserted into partitioned table

Bug #54487	Wrong data inserted into partitioned table
Submitted:	14 Jun 2010 15:00	Modified:	7 Jul 2010 17:05
Reporter:	Magnus Blåudd	Email Updates:
Status:	Closed	Impact on me:	None
Category:	MySQL Cluster: Cluster (NDB) storage engine	Severity:	S2 (Serious)
Version:	7.0.16	OS:	Windows
Assigned to:		CPU Architecture:	Any

Description:
The below four testcases fails because wrong data seem to be inserted into the table TestDist and this causes unexpected data to be read.

testPartitioning -n startTransactionHint_orderedIndex_mrr_userDefined T1
testPartitioning -n startTransactionHint_orderedIndex_mrr_native T1
testPartitioning -n startTransactionHint_orderedIndex_mrr_userDefined  --forceshortreqs T1
testPartitioning -n startTransactionHint_orderedIndex_mrr_native --forceshortreqs T1

How to repeat:
$> testPartitioning -n startTransactionHint_orderedIndex_mrr_userDefined T1
random seed: 1738687822
testPartitioning started [2010-06-14 16:45:14]
|- T1
- startTransactionHint_orderedIndex_mrr_userDefined started [2010-06-14 16:45:14]
  |- run_create_dist_table started [2010-06-14 16:45:14]
-- DistTest --
Version: 2
Fragment type: 7
K Value: 6
Min load factor: 78
Max load factor: 80
Temporary table: no
Number of attributes: 3
Number of primary keys: 2
Length of frm data: 0
Row Checksum: 1
Row GCI: 1
SingleUserMode: 0
ForceVarPart: 0
FragmentCount: 8
TableStatus: Unknown(3)
-- Attributes --
DKey Unsigned PRIMARY KEY DISTRIBUTION KEY AT=FIXED ST=MEMORY
PKey2 Unsigned PRIMARY KEY AT=FIXED ST=MEMORY
Result Unsigned NULL AT=FIXED ST=MEMORY

Primary Index created successfully
Index on Result created successfully
  |- run_create_dist_table PASSED [2010-06-14 16:45:18]
  |- run_dist_test started [2010-06-14 16:45:18]
Table has 8 physical partitions
Testing with 17 discrete distribution key values
Connecting to mgmsrv at
Checking MRR indexscan distribution awareness when distribution key part of bounds
User Defined Partitioning scheme
Got bad values.  Dkey : 0 Pkey2 : 0 Result : -842150451
  |- run_dist_test FAILED [2010-06-14 16:45:18]
- startTransactionHint_orderedIndex_mrr_userDefined FAILED [2010-06-14 16:45:18]
Completed testPartitioning [2010-06-14 16:45:18]
= SUMMARY OF TEST EXECUTION ==============
startTransactionHint_orderedIndex_mrr_userDefined
 T1         FAIL  4 secs (4621 ms)
==========================================
1 test(s) executed
0 test(s) OK
1 test(s) failed
Total time : 4 seconds (4621 ms)

$ ../../tools/Debug/ndb_show_tables.exe
id    type                 state    logging database     schema   name
9     OrderedIndex         Online   No      sys          def      ResultIndex
1     0                    Online   -                             DEFAULT-HASHMAP-240-2
3     SystemTable          Online   Yes     sys          def      NDB$EVENTS_0
6     UserTable            Online   Yes     mysql        def      ndb_apply_status
0     IndexTrigger         Online   -                             NDB$INDEX_8_CUSTOM
7     UserTable            Online   Yes     TEST_DB      def      DistTest
1     IndexTrigger         Online   -                             NDB$INDEX_9_CUSTOM
5     UserTable            Online   Yes     mysql        def      NDB$BLOB_4_3
8     OrderedIndex         Online   No      sys          def      PRIMARY
2     SystemTable          Online   Yes     sys          def      SYSTAB_0
4     UserTable            Online   Yes     mysql        def      ndb_schema
1     TableEvent           Online   -                             REPL$mysql/ndb_schema
2     TableEvent           Online   -                             NDB$BLOBEVENT_REPL$mysql/ndb_schema_3
3     TableEvent           Online   -                             REPL$mysql/ndb_apply_status

NDBT_ProgramExit: 0 - OK

Examining the inserted data shows 0 in the Result column, which is expected to be Pkey*Pkey

$ ../../tools/Debug/ndb_select_all.exe DistTest
DKey    PKey2   Result
9       77      0
1       188     0
1       256     0
9       26      0
1       477     0
<snip>
0       136     0
16      237     0
16      492     0
1000 rows returned

testPartitioning also fails on Solaris with bus error in the same testcase, so I suspect that the test program is doing something wrong when "writing" the values into the record.

Core was generated by `/export/home/tmp/ndbdev/atrt/run-sols/bin/testPartitioning'.
Program terminated with signal 10, Bus error.
#0  0x00021c3c in run_dist_test (ctx=0x9f2b8, step=0x76e60)
    at testPartitioning.cpp:797
797	    dKeyVal= r % parts;

NdbApi signal trace with -r 10

Attachment: 1.log (application/octet-stream, text), 66.41 KiB.

The INSERT of r=2 on Windows shows missing data in the ATTRINFO long section:
---- Send ----- Signal ----------------
r.bn: 245 "DBTC", r.proc: 1, gsn: 12 "TCKEYREQ" prio: 1
s.bn: 32768 "API", s.proc: 192, s.sigId: 0 length: 9 trace: 1 #sec: 2 fragInf: 0
 apiConnectPtr: H'00000022, apiOperationPtr: H'00000014
 Operation: Insert, Flags: Start Execute Commit NoDisk AbortOnError  d-key
 keyLen: 0, attrLen: 0, AI in this: 0, tableId: 4, tableSchemaVer: 7, API Ver: 16
 transId(1, 2): (H'00000002, H'0000c000)
 -- Variable Data --
 H'00000002
SECTION 0 type=generic size=2
 H'00000002 H'00000002
SECTION 1 type=generic size=5
 H'00000004 H'00000002 H'00010004 H'00000002 H'00020000

compared to Linux:
---- Send ----- Signal ----------------
r.bn: 245 "DBTC", r.proc: 1, gsn: 12 "TCKEYREQ" prio: 1
s.bn: 32768 "API", s.proc: 192, s.sigId: 0 length: 9 trace: 1 #sec: 2 fragInf: 0
 apiConnectPtr: H'00000033, apiOperationPtr: H'00000014
 Operation: Insert, Flags: Start Execute Commit NoDisk AbortOnError  d-key
 keyLen: 0, attrLen: 0, AI in this: 0, tableId: 7, tableSchemaVer: 8, API Ver: 16
 transId(1, 2): (H'00000002, H'0000c000)
 -- Variable Data --
 H'00000002
SECTION 0 type=generic size=2
 H'00000002 H'00000002
SECTION 1 type=generic size=6
 H'00000004 H'00000002 H'00010004 H'00000002 H'00020004 H'00000004

nullbit for the third attribute is set

==12384== Conditional jump or move depends on uninitialised value(s)
==12384==    at 0x4F1C48A: NdbRecord::Attr::is_null(char const*) const (NdbRecord.hpp:144)
==12384==    by 0x4F1ABB2: NdbOperation::buildSignalsNdbRecord(unsigned int, unsigned long long, unsigned int const*) (NdbOperationExec.cpp:1173)
==12384==    by 0x4F0B7F8: NdbTransaction::setupRecordOp(NdbOperation::OperationType, NdbOperation::LockMode, NdbOperation::AbortOption, NdbRecord const*, char const*, NdbRecord const*, char const*, unsigned char const*, NdbOperation::OperationOptions const*, unsigned int, NdbLockHandle const*) (NdbTransaction.cpp:2388)
==12384==    by 0x4F0BA1D: NdbTransaction::insertTuple(NdbRecord const*, char const*, NdbRecord const*, char const*, unsigned char const*, NdbOperation::OperationOptions const*, unsigned int) (NdbTransaction.cpp:2476)
==12384==    by 0x4F0BA9E: NdbTransaction::insertTuple(NdbRecord const*, char const*, unsigned char const*, NdbOperation::OperationOptions const*, unsigned int) (NdbTransaction.cpp:2495)
==12384==    by 0x4181B3: load_dist_table(Ndb*, int, int) (testPartitioning.cpp:814)
==12384==    by 0x4195E2: run_dist_test(NDBT_Context*, NDBT_Step*) (testPartitioning.cpp:1186)

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/111091

Pushed to 7.0.16 and 7.1.5

Problem was in test program which didn't set nul bit properly for an inserted attribute.

Pushed into 5.1.44-ndb-7.0.16 (revid:magnus.blaudd@sun.com-20100615090935-ekk0k78ydvxmawgk) (version source revid:magnus.blaudd@sun.com-20100615090935-ekk0k78ydvxmawgk) (merge vers: 5.1.44-ndb-7.0.16) (pib:16)

Since this was a change in test code only, there are no user-facing changes to document; closed without without action.