Details
-
Type:
Bug
-
Status: Closed
-
Priority:
Major
-
Resolution: Fixed
-
Affects Version/s: None
-
Fix Version/s: 10.0.0
-
Component/s: None
-
Labels:None
Description
This is most likely either the same problem as MDEV-476, or a closely related one. The test case is exactly the same, except that in this bug we execute the flow in the second connection and get the assertion failure; while in MDEV-476 we execute the flow in the first connection, and get the crash. It happens both with MTR and if I start the server and execute the test manually.
With MTR, the flow, according to the general log, is such:
- server starts;
- connection 1 connects;
- connection 1 executes MTR service stuff;
- connection 1 quits;
- connection 2 connects;
- connection 2 executes the test case statements;
- server crashes
This bug:
- server starts;
- connection 1 connects;
- connection 1 executes MTR service stuff;
- connection 1 quits;
- connection 2 connects;
- connection 3 connects;
- connection 3 executes the test case statements;
- assertion fails.
When I execute it manually, I do it even simpler:
- start the server;
- connection 1 connects;
- connection 1 executes the test case statements;
- server crashes.
This bug:
- start the server;
- connection 1 connects;
- connection 1 quits;
- connection 2 connects;
- connection 2 executes the test case statements;
- assertion fails.
I find the difference in behavior disturbing, so I'll file it separately just so it doesn't get lost. Please feel free to close it as a duplicate if that's what it is.
mysqld: sql/field.cc:3795: virtual longlong Field_longlong::val_int(): Assertion `!table || (!table->read_set || bitmap_is_set(table->read_set, field_index))' failed.
#8 0xb7498014 in __assert_fail () from /lib/libc.so.6
#9 0x083eb8fb in Field_longlong::val_int (this=0x97cf9e0)
at sql/field.cc:3795
#10 0x0859216e in BigintDataConverter::mariadb_to_cassandra(char**, int*) ()
#11 0x08590d12 in ha_cassandra::index_read_map (this=0x97cf580,
buf=0x97cf9a0 "\377", key=0x97d73e8 "\001", keypart_map=1,
find_flag=HA_READ_KEY_EXACT)
at storage/cassandra/ha_cassandra.cc:648
#12 0x085917ad in ha_cassandra::rnd_pos (this=0x97cf580,
buf=0x97cf9a0 "\377", pos=0x97d73e8 "\001")
at storage/cassandra/ha_cassandra.cc:882
#13 0x082651eb in handler::ha_rnd_pos (this=0x97cf580,
buf=0x97cf9a0 "\377", pos=0x97d73e8 "\001")
at sql/sql_class.h:4283
#14 0x0851989b in rr_from_pointers (info=0xacec6714)
at sql/records.cc:529
#15 0x0853b984 in mysql_delete (thd=0x97afe68, table_list=0x97b23e0,
conds=0x0, order_list=0x97b1a20, limit=1, options=0)
at sql/sql_delete.cc:327
#16 0x08278fe7 in mysql_execute_command (thd=0x97afe68)
at sql/sql_parse.cc:3050
#17 0x08280453 in mysql_parse (thd=0x97afe68,
rawbuf=0x97b2320 "DELETE FROM t1 ORDER BY a LIMIT 1", length=33,
parser_state=0xacec6da4)
at sql/sql_parse.cc:5736
#18 0x0827489c in dispatch_command (command=COM_QUERY, thd=0x97afe68,
packet=0x97c6da1 "DELETE FROM t1 ORDER BY a LIMIT 1",
packet_length=33)
at sql/sql_parse.cc:1055
#19 0x08273d61 in do_command (thd=0x97afe68)
at sql/sql_parse.cc:794
#20 0x0835fb11 in do_handle_one_connection (thd_arg=0x97afe68)
at sql/sql_connect.cc:1253
#21 0x0835f65c in handle_one_connection (arg=0x97afe68)
at sql/sql_connect.cc:1168
#22 0x0858bf70 in pfs_spawn_thread (arg=0x97e7d50)
at storage/perfschema/pfs.cc:1015
#23 0xb7811b25 in start_thread () from /lib/libpthread.so.0
revision-id: psergey@askmonty.org-20120821143827-1gfv6fmua0cu29sl date: 2012-08-21 18:38:27 +0400 build-date: 2012-08-23 00:46:27 +0400 revno: 3492
Test case:
--connect (con1,localhost,root,,) DROP TABLE IF EXISTS t1; CREATE TABLE t1 (rowkey BIGINT PRIMARY KEY, a BIGINT) ENGINE=CASSANDRA thrift_host='localhost' keyspace='storage_engine' column_family = 'colfam_t1'; INSERT INTO t1 VALUES (1,1),(2,2); DELETE FROM t1 ORDER BY a LIMIT 1;
Gliffy Diagrams
Attachments
Issue Links
Activity
- All
- Comments
- Work Log
- History
- Activity
- Transitions
This should be fixed by
MDEV-476. Please re-open if not.