Bug #31497 Drop of table with conflict resolution causes mysqld to crash
Submitted: 10 Oct 2007 1:02 Modified: 10 Oct 2007 8:05
Reporter: Jonathan Miller Email Updates:
Status: Closed
Category:Server: Cluster Severity:S1 (Critical)
Version:mysql-5.1-telco OS:Linux (64 Bit)
Assigned to: Tomas Ulin Target Version:

[10 Oct 2007 1:02] Jonathan Miller 
Description:
#0  0x0000003aa5f09737 in pthread_kill () from /lib64/tls/libpthread.so.0
#1  0x00000000007fe058 in write_core (sig=11) at stacktrace.c:240
#2  0x0000000000673fb3 in handle_segfault (sig=11) at mysqld.cc:2283
#3  <signal handler called>
#4  0x000000000099e8c0 in NdbTableImpl::getImpl (t=@0xa5a5a5a5a5a5a5a5)
    at NdbDictionaryImpl.hpp:827
#5  0x00000000009d84d6 in NdbDictionary::Dictionary::removeTableGlobal (this=0xffad98,
    ndbtab=@0xa5a5a5a5a5a5a5a5, invalidate=0) at NdbDictionary.cpp:1592
#6  0x0000000000862722 in ndbcluster_real_free_share (share=0x40c02e38)
    at ha_ndbcluster.cc:9736
#7  0x000000000085fae1 in ndbcluster_end (hton=0xffde08, type=HA_PANIC_CLOSE)
    at ha_ndbcluster.cc:8736
#8  0x0000000000788c39 in ha_finalize_handlerton (plugin=0xff1a38) at handler.cc:391
#9  0x000000000083ad93 in plugin_deinitialize (plugin=0xff1a38, ref_check=true)
    at sql_plugin.cc:812
#10 0x000000000083b0d8 in reap_plugins () at sql_plugin.cc:900
#11 0x000000000083c7a8 in plugin_shutdown () at sql_plugin.cc:1493
#12 0x0000000000672921 in clean_up (print_message=true) at mysqld.cc:1207
#13 0x0000000000672752 in unireg_end () at mysqld.cc:1137
#14 0x0000000000672597 in kill_server (sig_ptr=0x0) at mysqld.cc:1076
#15 0x00000000006725bb in kill_server_thread (arg=0x40bc213c) at mysqld.cc:1097
#16 0x0000003aa5f0610a in start_thread () from /lib64/tls/libpthread.so.0
#17 0x0000003aa56c68b3 in clone () from /lib64/tls/libc.so.6
#18 0x0000000000000000 in ?? ()
(gdb) frame 3
#3  <signal handler called>
(gdb) frame 4
#4  0x000000000099e8c0 in NdbTableImpl::getImpl (t=@0xa5a5a5a5a5a5a5a5)
    at NdbDictionaryImpl.hpp:827
827       return t.m_impl;
(gdb) list
822     }
823
824     inline
825     NdbTableImpl &
826     NdbTableImpl::getImpl(const NdbDictionary::Table & t){
827       return t.m_impl;
828     }
829
830     inline
831     NdbColumnImpl *
(gdb) frame 5
#5  0x00000000009d84d6 in NdbDictionary::Dictionary::removeTableGlobal (this=0xffad98,
    ndbtab=@0xa5a5a5a5a5a5a5a5, invalidate=0) at NdbDictionary.cpp:1592
1592      return m_impl.releaseTableGlobal(NdbTableImpl::getImpl(ndbtab), invalidate);
(gdb) list
1587
1588    int
1589    NdbDictionary::Dictionary::removeTableGlobal(const Table &ndbtab,
1590                                                 int invalidate) const
1591    {
1592      return m_impl.releaseTableGlobal(NdbTableImpl::getImpl(ndbtab), invalidate);
1593    }
1594
1595    NdbRecord *
1596    NdbDictionary::Dictionary::createRecord(const Table *table,
(gdb) frame 6
#6  0x0000000000862722 in ndbcluster_real_free_share (share=0x40c02e38)
    at ha_ndbcluster.cc:9736
9736        dict->removeTableGlobal(*(*share)->m_cfn_share->m_ex_tab, 0);
(gdb) list
9731
9732    #ifdef HAVE_NDB_BINLOG
9733      if ((*share)->m_cfn_share && (*share)->m_cfn_share->m_ex_tab && g_ndb)
9734      {
9735        NDBDICT *dict= g_ndb->getDictionary();
9736        dict->removeTableGlobal(*(*share)->m_cfn_share->m_ex_tab, 0);
9737        (*share)->m_cfn_share->m_ex_tab= 0;
9738      }
9739      (*share)->new_op= 0;
9740      if ((*share)->event_data)

How to repeat:
./BUILD/compile-pentium64-debug-max

 ./mysql-test-run.pl --do-test=rpl_ndb_rep_error --mysqld=--binlog-format=row --force

--source include/have_ndb.inc
--source include/have_binlog_format_row.inc
--source include/master-slave.inc
CREATE TABLE mysql.ndb_replication
  (db VARBINARY(63),
   table_name VARBINARY(63),
   server_id INT UNSIGNED,
   binlog_type INT UNSIGNED,
   conflict_fn VARBINARY(128),
   PRIMARY KEY USING HASH (db,table_name,server_id))
  ENGINE=NDB PARTITION BY KEY(db,table_name);
insert into mysql.ndb_replication values ("test", "t1", 0, NULL, "NDB$MAX(X)");
create table t1 (a int key, X int) engine ndb;
drop table t1;

Suggested fix:
Seems to be passing an invalid memory address (t=@0xa5a5a5a5a5a5a5a5)
[10 Oct 2007 1:04] Jonathan Miller 
I have repeated this several time and narrowed it down to the test case listed in this
bug.

FYI:
Errors are (from /data0/pending/mysql-5.1-telco/mysql-test/var/log/mysqltest-time) :
mysqltest: At line 60: query 'drop table t1' failed: 2013: Lost connection to MySQL
server during query

It happens during the drop of t1;
[10 Oct 2007 8:04] 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/35263

ChangeSet@1.2623, 2007-10-10 10:05:14+02:00, tomas@whalegate.ndb.mysql.com +1 -0
  bug#31497 NdbTableImpl::getImpl(const NdbDictionary::Table & t) cause mysqld core on
drop
  - structure allocated even in error case, in which variables become uninitialized
[10 Oct 2007 8:05] Tomas Ulin 
no need to document, bug in work in progress, never released