[MDEV-5091] Assertion `!table || (!table->read_set || bitmap_is_set(table->read_set, field_index))' fails with UNION, constant table, view Created: 2013-10-01  Updated: 2013-11-15  Resolved: 2013-11-15

Status: Closed
Project: MariaDB Server
Component/s: None
Affects Version/s: 10.0.4, 5.3.12, 5.5.33a
Fix Version/s: 5.5.34, 10.0.6, 5.3.13

Type: Bug Priority: Major
Reporter: Elena Stepanova Assignee: Igor Babaev
Resolution: Fixed Votes: 0
Labels: None

Issue Links:
Relates

 Description   

CREATE TABLE t1 (i INT, c CHAR(1)) ENGINE=MyISAM;
CREATE VIEW v1 AS SELECT * FROM t1;
INSERT INTO t1 VALUES (6,'b');
 
( SELECT i FROM v1 GROUP BY i ORDER BY CONCAT( c, c ) LIMIT 1 )
UNION 
( SELECT i FROM t1 )
;

#6  0x00007f7bd57180ee in __assert_fail_base (fmt=<optimized out>, assertion=0xcb2650 "!table || (!table->read_set || bitmap_is_set(table->read_set, field_index))", file=0xcb256f "field.cc", line=<optimized out>, function=<optimized out>) at assert.c:94
#7  0x00007f7bd5718192 in __GI___assert_fail (assertion=0xcb2650 "!table || (!table->read_set || bitmap_is_set(table->read_set, field_index))", file=0xcb256f "field.cc", line=6406, function=0xcb4520 "virtual String* Field_string::val_str(String*, String*)") at assert.c:103
#8  0x0000000000644dc7 in Field_string::val_str (this=0x7f7bbc02f490, val_buffer=0x7f7bbc03e508, val_ptr=0x7f7bbc01aae8) at field.cc:6406
#9  0x0000000000582323 in Item_field::val_str (this=0x7f7bbc01aad0, str=0x7f7bbc03e508) at item.cc:2345
#10 0x000000000058e8d4 in Item_direct_ref::val_str (this=0x7f7bbc038c00, tmp=0x7f7bbc03e508) at item.cc:6953
#11 0x000000000059bdee in Item_direct_view_ref::val_str (this=0x7f7bbc038c00, tmp=0x7f7bbc03e508) at item.h:3036
#12 0x00000000005e18ef in Item_func_concat::val_str (this=0x7f7bbc019968, str=0x7f7bbc03e508) at item_strfunc.cc:293
#13 0x0000000000585f74 in Item_copy_string::copy (this=0x7f7bbc03e4f0) at item.cc:3701
#14 0x000000000073bc2a in copy_fields (param=0x7f7bbc037d38) at sql_select.cc:20639
#15 0x000000000073378e in end_send_group (join=0x7f7bbc037b70, join_tab=0x0, end_of_records=false) at sql_select.cc:17380
#16 0x000000000072fc3f in do_select (join=0x7f7bbc037b70, fields=0x7f7bbc037f00, table=0x0, procedure=0x0) at sql_select.cc:15786
#17 0x000000000070fc2a in JOIN::exec (this=0x7f7bbc037b70) at sql_select.cc:2778
#18 0x000000000089b2fd in st_select_lex_unit::exec (this=0x1e28e58) at sql_union.cc:657
#19 0x000000000089919c in mysql_union (thd=0x1e268c8, lex=0x1e28db8, result=0x7f7bbc01ad58, unit=0x1e28e58, setup_tables_done_option=0) at sql_union.cc:35
#20 0x0000000000706df0 in handle_select (thd=0x1e268c8, lex=0x1e28db8, result=0x7f7bbc01ad58, setup_tables_done_option=0) at sql_select.cc:266
#21 0x0000000000693096 in execute_sqlcom_select (thd=0x1e268c8, all_tables=0x7f7bbc0191c0) at sql_parse.cc:5172
#22 0x0000000000689e5e in mysql_execute_command (thd=0x1e268c8) at sql_parse.cc:2305
#23 0x0000000000695b20 in mysql_parse (thd=0x1e268c8, rawbuf=0x7f7bbc018f40 "( SELECT i FROM v1 GROUP BY i ORDER BY CONCAT( c, c ) LIMIT 1 )\nUNION \n( SELECT i FROM t1 )", length=91, found_semicolon=0x7f7bc85477e0) at sql_parse.cc:6173
#24 0x000000000068757b in dispatch_command (command=COM_QUERY, thd=0x1e268c8, packet=0x1ea0b29 "( SELECT i FROM v1 GROUP BY i ORDER BY CONCAT( c, c ) LIMIT 1 )\nUNION \n( SELECT i FROM t1 )\n", packet_length=92) at sql_parse.cc:1243
#25 0x00000000006867ec in do_command (thd=0x1e268c8) at sql_parse.cc:923
#26 0x0000000000683686 in handle_one_connection (arg=0x1e268c8) at sql_connect.cc:1231
#27 0x00007f7bd62b3e9a in start_thread (arg=0x7f7bc8548700) at pthread_create.c:308
#28 0x00007f7bd57dccbd in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:112

Stack trace from

revno: 3699
revision-id: sanja@askmonty.org-20130925123013-qbytshoda82jzqkn
branch nick: 5.3

EXPLAIN also crashes.



 Comments   
Comment by Igor Babaev [ 2013-11-15 ]

A fix for the bug was pushed into 5.3, but it turned out to be incorrect and caused a regression reported in mdev-5288.
The correct patch was pushed when fixing mdev-5288

Generated at Thu Feb 08 07:01:35 UTC 2024 using Jira 8.20.16#820016-sha1:9d11dbea5f4be3d4cc21f03a88dd11d8c8687422.