Description:
This is a sideffect of the ndbcluster_print_error() (called from
ndbcluster_commit and ndbcluster_rollback). The function realises that
it "knows nothing" so it creates brand new ha_ndbcluster in order to be
able to call print_error() function. Unfortunately the fresh handler hasn't been
open()ed and thus table pointer is not set.
How to repeat:
./mtr ndb_insert
(gdb) where
#0 __pthread_kill (threadid=<value optimized out>,
signo=<value optimized out>)
at ../nptl/sysdeps/unix/sysv/linux/pthread_kill.c:63
#1 0x0000000000c0ed5f in my_write_core (sig=11)
at /home/msvensson/mysql/5.5-telco-7.0/mysys/stacktrace.c:328
#2 0x000000000058a86a in handle_segfault (sig=11)
at /home/msvensson/mysql/5.5-telco-7.0/sql/mysqld.cc:2519
#3 <signal handler called>
#4 0x000000000079291a in handler::get_dup_key (this=0x7fb2e3bd7b70,
error=121) at /home/msvensson/mysql/5.5-telco-7.0/sql/handler.cc:3007
#5 0x0000000000791b9c in handler::print_error (this=0x7fb2e3bd7b70,
error=121, errflag=0)
at /home/msvensson/mysql/5.5-telco-7.0/sql/handler.cc:2669
#6 0x000000000096e825 in ha_ndbcluster::print_error (this=0x7fb2e3bd7b70,
error=121, errflag=0)
at /home/msvensson/mysql/5.5-telco-7.0/sql/ha_ndbcluster.cc:10575
#7 0x000000000096e961 in ndbcluster_print_error (error=121, error_op=0x0)
at /home/msvensson/mysql/5.5-telco-7.0/sql/ha_ndbcluster.cc:10600
#8 0x00000000009630ba in ndbcluster_commit (hton=0x1e6c7f0, thd=0x25d03f0,
all=false)
at /home/msvensson/mysql/5.5-telco-7.0/sql/ha_ndbcluster.cc:7012
#9 0x000000000078ebc3 in ha_commit_one_phase (thd=0x25d03f0, all=false)
at /home/msvensson/mysql/5.5-telco-7.0/sql/handler.cc:1275
#10 0x000000000078e9e1 in ha_commit_trans (thd=0x25d03f0, all=false)
at /home/msvensson/mysql/5.5-telco-7.0/sql/handler.cc:1221
#11 0x0000000000717808 in trans_commit_stmt (thd=0x25d03f0)
at /home/msvensson/mysql/5.5-telco-7.0/sql/transaction.cc:271
#12 0x000000000062e882 in mysql_execute_command (thd=0x25d03f0)
at /home/msvensson/mysql/5.5-telco-7.0/sql/sql_parse.cc:4375
#13 0x0000000000630f66 in mysql_parse (thd=0x25d03f0,
rawbuf=0x263c200 "INSERT INTO t1 VALUES \n(-1,-1,-1),(1,1,1),(2,2,2),(3,3,3),(4,4,4),(5,5,5),\n(6,6,6),(7,7,7),(8,8,8),(9,9,9),(10,10,10),(9999,9999,9999)", length=134, parser_state=0x7fb2e3bdc140)
Suggested fix:
Probably need to rewrite ndb_print_error() function to print a user friendly error message for the errors that can occur during commit/rollback without instantiating a new handler. Should be quite selective which errors to handle here. For those errors that are not handled, the MySQL Server will print something like "error X occured during commit" and that is in most cases good enough. Especially if we have pushed up the orignal NDB error as a warning.
Description: This is a sideffect of the ndbcluster_print_error() (called from ndbcluster_commit and ndbcluster_rollback). The function realises that it "knows nothing" so it creates brand new ha_ndbcluster in order to be able to call print_error() function. Unfortunately the fresh handler hasn't been open()ed and thus table pointer is not set. How to repeat: ./mtr ndb_insert (gdb) where #0 __pthread_kill (threadid=<value optimized out>, signo=<value optimized out>) at ../nptl/sysdeps/unix/sysv/linux/pthread_kill.c:63 #1 0x0000000000c0ed5f in my_write_core (sig=11) at /home/msvensson/mysql/5.5-telco-7.0/mysys/stacktrace.c:328 #2 0x000000000058a86a in handle_segfault (sig=11) at /home/msvensson/mysql/5.5-telco-7.0/sql/mysqld.cc:2519 #3 <signal handler called> #4 0x000000000079291a in handler::get_dup_key (this=0x7fb2e3bd7b70, error=121) at /home/msvensson/mysql/5.5-telco-7.0/sql/handler.cc:3007 #5 0x0000000000791b9c in handler::print_error (this=0x7fb2e3bd7b70, error=121, errflag=0) at /home/msvensson/mysql/5.5-telco-7.0/sql/handler.cc:2669 #6 0x000000000096e825 in ha_ndbcluster::print_error (this=0x7fb2e3bd7b70, error=121, errflag=0) at /home/msvensson/mysql/5.5-telco-7.0/sql/ha_ndbcluster.cc:10575 #7 0x000000000096e961 in ndbcluster_print_error (error=121, error_op=0x0) at /home/msvensson/mysql/5.5-telco-7.0/sql/ha_ndbcluster.cc:10600 #8 0x00000000009630ba in ndbcluster_commit (hton=0x1e6c7f0, thd=0x25d03f0, all=false) at /home/msvensson/mysql/5.5-telco-7.0/sql/ha_ndbcluster.cc:7012 #9 0x000000000078ebc3 in ha_commit_one_phase (thd=0x25d03f0, all=false) at /home/msvensson/mysql/5.5-telco-7.0/sql/handler.cc:1275 #10 0x000000000078e9e1 in ha_commit_trans (thd=0x25d03f0, all=false) at /home/msvensson/mysql/5.5-telco-7.0/sql/handler.cc:1221 #11 0x0000000000717808 in trans_commit_stmt (thd=0x25d03f0) at /home/msvensson/mysql/5.5-telco-7.0/sql/transaction.cc:271 #12 0x000000000062e882 in mysql_execute_command (thd=0x25d03f0) at /home/msvensson/mysql/5.5-telco-7.0/sql/sql_parse.cc:4375 #13 0x0000000000630f66 in mysql_parse (thd=0x25d03f0, rawbuf=0x263c200 "INSERT INTO t1 VALUES \n(-1,-1,-1),(1,1,1),(2,2,2),(3,3,3),(4,4,4),(5,5,5),\n(6,6,6),(7,7,7),(8,8,8),(9,9,9),(10,10,10),(9999,9999,9999)", length=134, parser_state=0x7fb2e3bdc140) Suggested fix: Probably need to rewrite ndb_print_error() function to print a user friendly error message for the errors that can occur during commit/rollback without instantiating a new handler. Should be quite selective which errors to handle here. For those errors that are not handled, the MySQL Server will print something like "error X occured during commit" and that is in most cases good enough. Especially if we have pushed up the orignal NDB error as a warning.