Bug #27737 Erroneous usage of blobs via ndbapi may cause mysqld to crash
Submitted: 10 Apr 2007 17:16 Modified: 10 May 2007 10:21
Reporter: Jonathan Miller Email Updates:
Status: Verified Impact on me:
None 
Category:MySQL Cluster: NDB API Severity:S3 (Non-critical)
Version:mysql-5.1 OS:Linux (32 bit)
Assigned to: Assigned Account CPU Architecture:Any
Triage: Triaged: D1 (Critical) / R6 (Needs Assessment) / E6 (Needs Assessment)

[10 Apr 2007 17:16] Jonathan Miller
Description:
I setup DbAsyncGenerator to use tables created through MySQL to have ability to replicate the tables. Right after starting the NDB API test the master mysqld core repeatedly:

Cannot determine thread, fp=0xb4b85cd8, backtrace may not be correct.
Stack range sanity check OK, backtrace follows:
0x821d9a2
0x85001e1
0x8500282
0x8307424
0x83227f6
0x8326407
0x640bd4
0x5984fe

0x821d9a2 handle_segfault + 560
0x85001e1 _ZN7NdbBlob15readDataPrivateEPcRj + 1027
0x8500282 _ZN7NdbBlob8readDataEPvRj + 82
0x8307424 _Z19get_ndb_blobs_valueP8st_tableP8NdbValueRPcRjl + 342
0x83227f6 _Z35ndb_binlog_thread_handle_data_eventP3NdbP17NdbEventOperationR20ndb_binlog_index_rowRN8injector11transactionE + 410
0x8326407 ndb_binlog_thread_func + 4437
0x640bd4 (?)
0x5984fe (?)

#0  0x004af402 in __kernel_vsyscall ()
#1  0x0064364f in pthread_kill () from /lib/libpthread.so.0
#2  0x083706a1 in write_core ()
#3  0x0821dab2 in handle_segfault ()
#4  <signal handler called>
#5  0x085001e1 in NdbBlob::readDataPrivate ()
#6  0x08500282 in NdbBlob::readData ()
#7  0x08307424 in get_ndb_blobs_value ()
#8  0x083227f6 in ndb_binlog_thread_handle_data_event ()
#9  0x08326407 in ndb_binlog_thread_func ()
#10 0x00640bd4 in start_thread () from /lib/libpthread.so.0
#11 0x005984fe in clone () from /lib/libc.so.6

How to repeat:
1) Create a 2 DN cluster with a master MySQLD running a bin log.
2) Using MySQL create database TEST_DB;
3) Using MySQL create the following tables;

 CREATE TABLE SESSION (NUMBER Char(12), SERVER_ID INT UNSIGNED, DATA TEXT(2000)  NOT NULL, PRIMARY KEY(NUMBER, SERVER_ID))ENGINE=NDB;

CREATE TABLE SERVER (SUFFIX Char(2), SERVER_ID INT Unsigned, NAME Char(32) NOT NULL, NO_OF_READ INT Unsigned NOT NULL, NO_OF_INSERT int Unsigned NOT NULL, NO_OF_DELETE int Unsigned NOT NULL, PRIMARY KEY(SUFFIX, SERVER_ID))ENGINE=NDB;

CREATE TABLE SUBSCRIBER (NUMBER Char(12) PRIMARY KEY, NAME Char(32) NOT NULL, GROUP_ID int Unsigned NOT NULL, LOCATION int Unsigned NOT NULL, SESSIONS int Unsigned NOT NULL, CHANGED_BY Char(32) NOT NULL, CHANGED_TIME Char(32) NOT NULL)ENGINE=NDB;

CREATE TABLE GROUP_T (GROUP_ID int Unsigned PRIMARY KEY, GROUP_NAME Char(32) NOT NULL, ALLOW_READ Char(1) NOT NULL, ALLOW_INSERT int Unsigned NOT NULL, ALLOW_DELETE int Unsigned NOT NULL)ENGINE=NDB;

4)  export NDB_CONNECTSTRING= 

5) load database using ./DbCreate

Using temporary tables
creating table SUBSCRIBER... it already exists
creating table GROUP_T... it already exists
creating table SESSION... it already exists
creating table SERVER... it already exists
Populating 20 'servers' ...
done
Populating 500000 'subscribers' ...
done
Populating 100 'groups' ...
done

6) Start test: ./DbAsyncGenerator -proc 3 -time 500000 -p 4
[25 Apr 2007 18:53] Pekka Nousiainen
> CREATE TABLE SESSION (NUMBER Char(12), SERVER_ID INT UNSIGNED, DATA TEXT(2000) 

DbAsync itself creates DATA CHAR(2000) on NDB API level.

Here it is redefined as a blob and when DbAsync tries to update it
as a char, the results are "undefined".

So this is "not a bug".

It may be possible to catch this NDB API mis-usage, or even better,
make it work as intended.