Bug #48700 Crash during scan in DBACC
Submitted: 11 Nov 2009 20:15 Modified: 18 Jan 2010 12:00
Reporter: Andrew Hutchings Email Updates:
Status: Closed Impact on me:
None 
Category:MySQL Cluster: Cluster (NDB) storage engine Severity:S2 (Serious)
Version:mysql-5.1-telco-7.0 OS:Any
Assigned to: Jonas Oreland CPU Architecture:Any

[11 Nov 2009 20:15] Andrew Hutchings 
Description:
Time: Monday 2 November 2009 - 17:29:28
Status: Temporary error, restart node
Message: Pointer too large (Internal error, programming error or missing error message, please report a bug)
Error: 2306
Error data: dbacc/DbaccMain.cpp
Error object: DBACC (Line: 6441) 0x0000000a
Program: /usr/local/mysql/bin/ndbmtd
Pid: 12400 thr: 3
Version: mysql-5.1.37 ndb-7.0.8a
Trace: /db2/ndb_11_trace.log.4 /db2/ndb_11_trace.log.4_t1 /db2/ndb_11_trace.log.4_t2 /db2/ndb_11_trace.log.4_t3 /db2/ndb_11_trace.log.4

How to repeat:
.
[15 Jan 2010 14:22] Jonas Oreland 
Note for myself: Found very very suspicious code in Dbacc,
  which when about to shrink/expand only considers the first 4
  scans!!!
[15 Jan 2010 14:45] Jonas Oreland 
boooooom tjackalack!
reproduced (with new test prg)
[15 Jan 2010 14:50] Jonas Oreland 
and fix is ofcourse embarrassingly trivial :(
[18 Jan 2010 9:48] 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/97216

3069 Jonas Oreland	2010-01-18
      ndb - bug#48700
        Make sure that checkScanShrink/expand checks all ongoing scans,
          not just the first 4
[18 Jan 2010 10:05] Jonas Oreland 
pushed to 6.2.19, 6.3.31 & 7.0.11
docs: If doing intensive insert/delete in parallel with high (acc) scan load
  data node could crash in Dbacc. Reason was that check for when to split/merge
  buckets was faulty and only considered the first 4 scans.
[18 Jan 2010 12:00] Jon Stephens 
Documented bugfix in the NDB-6.2.19, 6.3.31, and 7.0.11 changelogs, as follows:

        Performing intensive inserts and deletes in parallel with a high
        scan load could a data node crashes due to a failure in the
        DBACC kernel block. This was because checking for when to
        perform bucket splits or merges considered the first 4 scans
        only.

Closed.