MySQL Bugs: #10273: Internal program error (failed ndbrequire)

Bug #10273	Internal program error (failed ndbrequire)
Submitted:	29 Apr 2005 18:51	Modified:	1 May 2005 3:07
Reporter:	Ted Schundler	Email Updates:
Status:	Can't repeat	Impact on me:	None
Category:	MySQL Cluster: Cluster (NDB) storage engine	Severity:	S2 (Serious)
Version:	4.1.11	OS:	FreeBSD (FreeBSD 5.4)
Assigned to:		CPU Architecture:	Any

Description:
Date/Time: Thursday 28 April 2005 - 16:05:03
Type of error: error
Message: Internal program error (failed ndbrequire)
Fault ID: 2341
Problem data: DbtcMain.cpp
Object of reference: DBTC (Line: 12251) 0x00000002
ProgramName: /usr/local/libexec/ndbd
ProcessID: 93822
TraceFile: /var/db/mysql-cluster/ndb_2_trace.log.1
***EOM***
                                                                        

How to repeat:
It seems the following queries in a cron job was causing it:

$res=mysql_query("SELECT ID,DNS FROM ExternalAccess WHERE LENGTH(DNS)>0 AND AutoIP='Yes'");

while ($row=mysql_fetch_row($res)) {
  mysql_query("UPDATE ExternalAccess SET OldIP=IP,IP=INET_ATON('".gethostbyname($row[1])."') WHERE ID=".$row[0]);
}

And here is the schema for the table it used:

CREATE TABLE ExternalAccess (
  ID int(10) unsigned NOT NULL auto_increment,
  IP bigint(20) unsigned NOT NULL default '0',
  OldIP int(10) unsigned NOT NULL default '0',
  DNS varchar(80) NOT NULL default '',
  Port smallint(5) NOT NULL default '0',
  Notes varchar(255) NOT NULL default '',
  AutoIP enum('Yes','No') NOT NULL default 'No',
  `Cache` enum('Yes','No') NOT NULL default 'No',
  LastChange timestamp NOT NULL default CURRENT_TIMESTAMP on update CURRENT_TIMESTAMP,
  PRIMARY KEY  (ID),
  UNIQUE KEY IP (IP,DNS,Port)
) ENGINE=ndbcluster DEFAULT CHARSET=utf8 COMMENT='For building NAT/ipfw and DNS configurations';

Unfortunately after ndb_1 died (http://bugs.mysql.com/bug.php?id=10272) and node 1 restarted itself, this stopped happening on node 2.

Trace logs are too big to upload to the bug report btw. (They're 1M, limit is 200K)

Hi, I can't reproduce this bug.  Can you please send us a repeatable test-case that shows this behaviour ?

Thanks

No, like I mentioned, after ndb_1 crashed and restarted, ndb_2 stopped crashing on that query. (though they have had other problems since then like randomly stopping performing local checkpoints) At least unlike the bug that crashed ndb_2, for this one, I know the query that was causing the problem. And like I mentioned, and I provide a trace log.