LevelDB storage engine (MDEV-3841)

[MDEV-4047] LevelDB: Assertion `0' fails in Protocol::end_statement() on multi-table INSERT IGNORE Created: 2013-01-15  Updated: 2013-01-15  Resolved: 2013-01-15

Status: Closed
Project: MariaDB Server
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Technical task Priority: Major
Reporter: Elena Stepanova Assignee: Sergei Petrunia
Resolution: Fixed Votes: 0
Labels: leveldb

Issue Links:
Relates

 Description   

mysqld: mysql-5.6-leveldb/sql/protocol.cc:518: void Protocol::end_statement(): Assertion `0' failed.
00:47:20 UTC - mysqld got signal 6 ;

#9  0xb73c5167 in __assert_fail () from /lib/libc.so.6
#10 0x0830d0a1 in Protocol::end_statement (this=0x96631dc) at mysql-5.6-leveldb/sql/protocol.cc:518
#11 0x083a421c in dispatch_command (command=COM_QUERY, thd=0x9662e08, packet=0x97027c9 "DELETE IGNORE t1.*, t2.* FROM t1, t2 WHERE b < a", packet_length=48) at mysql-5.6-leveldb/sql/sql_parse.cc:1695
#12 0x083a265e in do_command (thd=0x9662e08) at mysql-5.6-leveldb/sql/sql_parse.cc:1036
#13 0x08372019 in do_handle_one_connection (thd_arg=0x9662e08) at mysql-5.6-leveldb/sql/sql_connect.cc:969
#14 0x08371bc2 in handle_one_connection (arg=0x9662e08) at mysql-5.6-leveldb/sql/sql_connect.cc:885
#15 0x08650a37 in pfs_spawn_thread (arg=0x95e6938) at mysql-5.6-leveldb/storage/perfschema/pfs.cc:1853
#16 0xb7719e32 in start_thread () from /lib/libpthread.so.0

Test case:

CREATE TABLE t1 (a int primary key) ENGINE=LevelDB;
INSERT INTO t1 VALUES (1),(2);
CREATE TABLE t2 (b int primary key) ENGINE=LevelDB;
INSERT INTO t2 SELECT * FROM t1;
DELETE IGNORE t1.*, t2.* FROM t1, t2 WHERE b < a;

revision-id: psergey@askmonty.org-20130114195003-fgp08gh4swgcf1cx
revno: 4486
branch-nick: mysql-5.6-leveldb



 Comments   
Comment by Sergei Petrunia [ 2013-01-15 ]

Investigation results:
The crash is caused by incorrect error handling at SQL layer. SQL layer cannot handle when the storage engine returns an error (HA_ERR_LOCK_WAIT_TIMEOUT) in this state:

#0 multi_delete::do_table_deletes (this=0x9959958, table=0x9966a58, ignore=true) at /home/psergey/dev2/mysql-5.6-leveldb/sql/sql_delete.cc:1017
#1 0x085b2ebb in multi_delete::do_deletes (this=0x9959958) at /home/psergey/dev2/mysql-5.6-leveldb/sql/sql_delete.cc:939
#2 0x085b2fd6 in multi_delete::send_eof (this=0x9959958) at /home/psergey/dev2/mysql-5.6-leveldb/sql/sql_delete.cc:1047
#3 0x083b709a in do_select (join=0x99599a0) at /home/psergey/dev2/mysql-5.6-leveldb/sql/sql_executor.cc:975
#4 0x083b8c61 in JOIN::exec (this=0x99599a0) at /home/psergey/dev2/mysql-5.6-leveldb/sql/sql_executor.cc:191
#5 0x08419299 in mysql_execute_select (thd=0x986b4c0, select_lex=0x986d084, free_join=true) at /home/psergey/dev2/mysql-5.6-leveldb/sql/sql_select.cc:1085
#6 0x08419ce4 in mysql_select (thd=0x986b4c0, tables=0x9958ea8, wild_num=0, fields=..., conds=0x99597e0, order=0x0, group=0x0, having=0x0, select_options=3489926016, result=0x9959958, unit=0x986cc2c, select_lex=0x986d084) at /home/psergey/dev2/mysql-5.6-leveldb/sql/sql_select.cc:1206
#7 0x083e6ecb in mysql_execute_command (thd=0x986b4c0) at /home/psergey/dev2/mysql-5.6-leveldb/sql/sql_parse.cc:3517
#8 0x083ec182 in mysql_parse (thd=0x986b4c0, rawbuf=0x99585d8 "DELETE IGNORE t1., t2. FROM t1, t2 WHERE b < a", length=48, parser_state=0xa5d16ab0) at /home/psergey/dev2/mysql-5.6-leveldb/sql/sql_parse.cc:6097
#9 0x083ecf7f in dispatch_command (command=COM_QUERY, thd=0x986b4c0, packet=0x99503c9 "DELETE IGNORE t1., t2. FROM t1, t2 WHERE b < a", packet_length=48) at /home/psergey/dev2/mysql-5.6-leveldb/sql/sql_parse.cc:1312

Comment by Sergei Petrunia [ 2013-01-15 ]

The root cause is that the locking system is not letting the thread take a lock on the same row two times. This should be fixed, somehow.

Comment by Sergei Petrunia [ 2013-01-15 ]

The root cause is that the locking system is not letting the thread take a lock on the same row two times. This should be fixed, somehow.

Comment by Sergei Petrunia [ 2013-01-15 ]

Fixed by allowing transaction to lock the same row multiple times.

Generated at Thu Feb 08 06:53:19 UTC 2024 using Jira 8.20.16#820016-sha1:9d11dbea5f4be3d4cc21f03a88dd11d8c8687422.