Crash on assertion in InnoDB rollback

[Alex Yurchenko]

After the latest merge with 5.1.37 nodes are easily crashed (almost instantaneously) with sqlgen even with 10 tables and 1000 rows setting:

090904 0:30:53 [Warning] local.c:wsdb_get_write_set():1165: Setting ws.last_seen_trx to 0
mysqld: handler.cc:1274: int ha_rollback_trans(THD*, bool): Assertion `thd->transaction.stmt.ha_list == __null || trans == &thd->transaction.stmt' failed.
090904 0:30:53 - mysqld got signal 6 ;
This could be because you hit a bug. It is also possible that this binary
or one of the libraries it was linked against is corrupt, improperly built,
or misconfigured. This error can also be caused by malfunctioning hardware.
We will try our best to scrape up some info that will hopefully help diagnose
the problem, but since we have already crashed, something is definitely wrong
and this may fail.

key_buffer_size=8384512
read_buffer_size=131072
max_used_connections=4
max_threads=151
threads_connected=4
It is possible that mysqld could use up to
key_buffer_size + (read_buffer_size + sort_buffer_size)*max_threads = 337751 K
bytes of memory
Hope that's ok; if not, decrease some variables in the equation.

thd: 0x998ad58
Attempting backtrace. You can use the following information to find out
where mysqld died. If you see no messages after this, something went
terribly wrong...
stack_bottom = 0x968eb3d0 thread_stack 0x30000
/home/ayurchen/devel/codership/galera/trunk/scripts/mysql/mysql-5.1.37-2872,1019M/mysql/libexec/mysqld(my_print_stacktrace+0x26)[0x85b981f]
/home/ayurchen/devel/codership/galera/trunk/scripts/mysql/mysql-5.1.37-2872,1019M/mysql/libexec/mysqld(handle_segfault+0x2c0)[0x824e0f4]
[0xb7f7d420]
/lib/tls/i686/cmov/libc.so.6(abort+0x101)[0xb7d9fa01]
/lib/tls/i686/cmov/libc.so.6(__assert_fail+0xee)[0xb7d9710e]
/home/ayurchen/devel/codership/galera/trunk/scripts/mysql/mysql-5.1.37-2872,1019M/mysql/libexec/mysqld(_Z17ha_rollback_transP3THDb+0xda)[0x8396664]
/home/ayurchen/devel/codership/galera/trunk/scripts/mysql/mysql-5.1.37-2872,1019M/mysql/libexec/mysqld(_Z9end_transP3THD25enum_mysql_completiontype+0x1ee)[0x825fffa]
/home/ayurchen/devel/codership/galera/trunk/scripts/mysql/mysql-5.1.37-2872,1019M/mysql/libexec/mysqld(_Z16dispatch_command19enum_server_commandP3THDPcj+0x2062)[0x826fa2a]
/home/ayurchen/devel/codership/galera/trunk/scripts/mysql/mysql-5.1.37-2872,1019M/mysql/libexec/mysqld(_Z10do_commandP3THD+0x569)[0x827093f]
/home/ayurchen/devel/codership/galera/trunk/scripts/mysql/mysql-5.1.37-2872,1019M/mysql/libexec/mysqld(handle_one_connection+0x14a)[0x8258116]
/lib/tls/i686/cmov/libpthread.so.0[0xb7f504fb]
/lib/tls/i686/cmov/libc.so.6(clone+0x5e)[0xb7e49e5e]
Trying to get some variables.
Some pointers may be invalid and cause the dump to abort...
thd->query at 0x99a5498 = UPDATE comm01 SET x = (x + 1) % 65537, y = ((y*x % 65537) + (47133*y % 65537) + (y*z % 65537)) % 65537, z = ((z*x % 65537) + (z*y % 65537) + (47133*z % 65537)) % 65537, r = 0.282626 WHERE p = 0
thd->thread_id=4
thd->killed=KILL_QUERY

[Seppo Jaakola (seppo-jaakola)]

The problem can be reproduced in gdb session, here is the stack trace:
(gdb) bt
#0 0x0073f402 in __kernel_vsyscall ()
#1 0x001a9fd0 in raise () from /lib/i686/nosegneg/libc.so.6
#2 0x001ab9b1 in abort () from /lib/i686/nosegneg/libc.so.6
#3 0x001a339b in __assert_fail () from /lib/i686/nosegneg/libc.so.6
#4 0x083968be in ha_rollback_trans (thd=0xa6b91888, all=true)
    at handler.cc:1273
#5 0x0825f164 in end_trans (thd=0xa6b91888, completion=ROLLBACK)
    at sql_parse.cc:767
#6 0x0826f667 in dispatch_command (command=COM_QUERY, thd=0xa6b91888,
    packet=0xa6ba0589 "", packet_length=32) at sql_parse.cc:1760
#7 0x0827057a in do_command (thd=0xa6b91888) at sql_parse.cc:948
#8 0x08257cf8 in handle_one_connection (arg=0xa6b91888) at sql_connect.cc:1155
#9 0x002fe4d2 in start_thread () from /lib/i686/nosegneg/libpthread.so.0
#10 0x0025448e in clone () from /lib/i686/nosegneg/libc.so.6

[Seppo Jaakola (seppo-jaakola)]

At the end of dispatch_command(), statement transaction was not rolled back, if BF abort interrupted connection during query processing phase