Crash in Field::is_null with join_cache_level=3 in maria-5.3-mwl128

Bug #663840 reported by Philip Stoev
6
This bug affects 1 person
Affects Status Importance Assigned to Milestone
MariaDB
Fix Released
Critical
Igor Babaev

Bug Description

The following query:

SELECT table1 .`col_int_nokey` , table2 .`col_varchar_key` , table1 .`col_varchar_key` , table2 .`col_time_key` , table2 .`col_date_key` , table2 .`col_int_key`
FROM CC table1 STRAIGHT_JOIN ( CC table2 JOIN CC table3 ON table3 .`col_varchar_nokey` ) ON table2 .`col_int_nokey` AND table3 .`col_varchar_key` = table2 .`col_varchar_nokey`
ORDER BY table1 .`col_date_key`;

causes the following backtrace:

#4 <signal handler called>
#5 0x081b9287 in Field::is_null (this=0xaecd830, row_offset=0) at field.h:337
#6 0x082d89d2 in JOIN_CACHE::read_record_field (this=0xaed6d08, copy=0xaed6f78, blob_in_rec_buff=false) at sql_join_cache.cc:1668
#7 0x082d8895 in JOIN_CACHE::read_all_record_fields (this=0xaed6d08) at sql_join_cache.cc:1600
#8 0x082d86b9 in JOIN_CACHE::get_record_by_pos (this=0xaed6d08, rec_ptr=0xaecb65a "\001v\t") at sql_join_cache.cc:1499
#9 0x082dab89 in JOIN_CACHE_BNLH::read_next_candidate_for_match (this=0xaed6d08, rec_ptr=0xaecb65a "\001v\t") at sql_join_cache.cc:3387
#10 0x082d9444 in JOIN_CACHE::join_matching_records (this=0xaed6d08, skip_last=false) at sql_join_cache.cc:2117
#11 0x082d8fe0 in JOIN_CACHE::join_records (this=0xaed6d08, skip_last=false) at sql_join_cache.cc:1926
#12 0x0831ffdb in sub_select_cache (join=0xaed00b0, join_tab=0xaed6098, end_of_records=false) at sql_select.cc:13103
#13 0x082d9694 in JOIN_CACHE::generate_full_extensions (this=0xaed6be0, rec_ptr=0xaecb599 "\003") at sql_join_cache.cc:2224
#14 0x082d9456 in JOIN_CACHE::join_matching_records (this=0xaed6be0, skip_last=false) at sql_join_cache.cc:2118
#15 0x082d8fe0 in JOIN_CACHE::join_records (this=0xaed6be0, skip_last=false) at sql_join_cache.cc:1926
#16 0x0831ffdb in sub_select_cache (join=0xaed00b0, join_tab=0xaed5ec4, end_of_records=false) at sql_select.cc:13103
#17 0x08320902 in evaluate_join_record (join=0xaed00b0, join_tab=0xaed5cf0, error=0) at sql_select.cc:13487
#18 0x083203f7 in sub_select (join=0xaed00b0, join_tab=0xaed5cf0, end_of_records=false) at sql_select.cc:13335
#19 0x0831f6ca in do_select (join=0xaed00b0, fields=0x0, table=0xaecb730, procedure=0x0) at sql_select.cc:12839
#20 0x08303adf in JOIN::exec (this=0xaed00b0) at sql_select.cc:1990
#21 0x08305df4 in mysql_select (thd=0xae59118, rref_pointer_array=0xae5ab94, tables=0xaeaabb0, wild_num=0, fields=..., conds=0x0, og_num=1, order=0xaeabff0,
    group=0x0, having=0x0, proc_param=0x0, select_options=2147764736, result=0xaeac090, unit=0xae5a7f8, select_lex=0xae5aa90) at sql_select.cc:2613
#22 0x082fe4af in handle_select (thd=0xae59118, lex=0xae5a79c, result=0xaeac090, setup_tables_done_option=0) at sql_select.cc:277
#23 0x0829b6d4 in execute_sqlcom_select (thd=0xae59118, all_tables=0xaeaabb0) at sql_parse.cc:5081
#24 0x082920b4 in mysql_execute_command (thd=0xae59118) at sql_parse.cc:2265
#25 0x0829d8b5 in mysql_parse (thd=0xae59118,
    inBuf=0xaeaa2e8 "SELECT table1 .`col_int_nokey` , table2 .`col_varchar_key` , table1 .`col_varchar_key` , table2 .`col_time_key` , table2 .`col_date_key` , table2 .`col_int_key`\nFROM CC table1 STRAIGHT_JOIN ( CC"..., length=381, found_semicolon=0xa95b6230) at sql_parse.cc:6027
#26 0x0828fae6 in dispatch_command (command=COM_QUERY, thd=0xae59118,
    packet=0xae71151 "SELECT table1 .`col_int_nokey` , table2 .`col_varchar_key` , table1 .`col_varchar_key` , table2 .`col_time_key` , table2 .`col_date_key` , table2 .`col_int_key`\nFROM CC table1 STRAIGHT_JOIN ( CC"..., packet_length=381) at sql_parse.cc:1184
#27 0x0828ef8c in do_command (thd=0xae59118) at sql_parse.cc:890
#28 0x0828c0ec in handle_one_connection (arg=0xae59118) at sql_connect.cc:1153
#29 0x00bea919 in start_thread () from /lib/libpthread.so.0
#30 0x00b2ccbe in clone () from /lib/libc.so.6

when executed with join_cache_level=3 , join_buffer_size=100

Revision history for this message
Philip Stoev (pstoev-askmonty) wrote :
Download full text (6.1 KiB)

Valgrind warnings:

==21368== Invalid read of size 1
==21368== at 0x4007637: memcpy (mc_replace_strmem.c:497)
==21368== by 0x82D8AF4: JOIN_CACHE::read_record_field(st_cache_field*, bool) (sql_join_cache.cc:1695)
==21368== by 0x82D8894: JOIN_CACHE::read_all_record_fields() (sql_join_cache.cc:1600)
==21368== by 0x82D86B8: JOIN_CACHE::get_record_by_pos(unsigned char*) (sql_join_cache.cc:1499)
==21368== by 0x82DAB88: JOIN_CACHE_BNLH::read_next_candidate_for_match(unsigned char*) (sql_join_cache.cc:3387)
==21368== by 0x82D9443: JOIN_CACHE::join_matching_records(bool) (sql_join_cache.cc:2117)
==21368== by 0x82D8FDF: JOIN_CACHE::join_records(bool) (sql_join_cache.cc:1926)
==21368== by 0x831FFDA: sub_select_cache(JOIN*, st_join_table*, bool) (sql_select.cc:13103)
==21368== by 0x82D9693: JOIN_CACHE::generate_full_extensions(unsigned char*) (sql_join_cache.cc:2224)
==21368== by 0x82D9455: JOIN_CACHE::join_matching_records(bool) (sql_join_cache.cc:2118)
==21368== by 0x82D8FDF: JOIN_CACHE::join_records(bool) (sql_join_cache.cc:1926)
==21368== by 0x831FFDA: sub_select_cache(JOIN*, st_join_table*, bool) (sql_select.cc:13103)
==21368== by 0x8320901: evaluate_join_record(JOIN*, st_join_table*, int) (sql_select.cc:13487)
==21368== by 0x83203F6: sub_select(JOIN*, st_join_table*, bool) (sql_select.cc:13335)
==21368== by 0x831F6C9: do_select(JOIN*, List<Item>*, st_table*, Procedure*) (sql_select.cc:12839)
==21368== by 0x8303ADE: JOIN::exec() (sql_select.cc:1990)

==21368== Address 0x186b3528 is 0 bytes after a block of size 192 alloc'd
==21368== at 0x4005BDC: malloc (vg_replace_malloc.c:195)
==21368== by 0x872E982: _mymalloc (safemalloc.c:137)
==21368== by 0x82D7599: JOIN_CACHE::alloc_buffer() (sql_join_cache.cc:827)
==21368== by 0x82D78FB: JOIN_CACHE::init() (sql_join_cache.cc:956)
==21368== by 0x82D9A6E: JOIN_CACHE_HASHED::init() (sql_join_cache.cc:2459)
==21368== by 0x82DAC64: JOIN_CACHE_BNLH::init() (sql_join_cache.cc:3417)
==21368== by 0x83136A2: check_join_cache_usage(st_join_table*, JOIN*, unsigned long long, unsigned int, bool*, bool*) (sql_select.cc:7672)
==21368== by 0x8313F9D: make_join_readinfo(JOIN*, unsigned long long, unsigned int) (sql_select.cc:7859)
==21368== by 0x83015E6: JOIN::optimize() (sql_select.cc:1282)
==21368== by 0x8305D6E: mysql_select(THD*, Item***, TABLE_LIST*, unsigned int, List<Item>&, Item*, unsigned int, st_order*, st_order*, Item*, st_order*, un
signed long long, select_result*, st_select_lex_unit*, st_select_lex*) (sql_select.cc:2599)
==21368== by 0x82FE4AE: handle_select(THD*, st_lex*, select_result*, unsigned long) (sql_select.cc:277)
==21368== by 0x829B6D3: execute_sqlcom_select(THD*, TABLE_LIST*) (sql_parse.cc:5081)
==21368== by 0x82920B3: mysql_execute_command(THD*) (sql_parse.cc:2265)
==21368== by 0x829D8B4: mysql_parse(THD*, char const*, unsigned int, char const**) (sql_parse.cc:6027)
==21368== by 0x828FAE5: dispatch_command(enum_server_command, THD*, char*, unsigned int) (sql_parse.cc:1184)
==21368== by 0x828EF8B: do_command(THD*) (sql_parse.cc:890)

==21368== Address 0x186b352a is 2 bytes after a block of size 192 alloc'...

Read more...

Revision history for this message
Philip Stoev (pstoev-askmonty) wrote :

Test case:

--source include/have_innodb.inc
SET SESSION join_cache_level=3;
SET SESSION join_buffer_size=100;

CREATE TABLE `CC` (
  `col_int_nokey` int(11) NOT NULL,
  `col_int_key` int(11) NOT NULL,
  `col_date_key` date NOT NULL,
  `col_time_key` time NOT NULL,
  `col_varchar_key` varchar(1) NOT NULL,
  `col_varchar_nokey` varchar(1) NOT NULL,
  KEY `col_int_key` (`col_int_key`),
  KEY `col_date_key` (`col_date_key`),
  KEY `col_time_key` (`col_time_key`),
  KEY `col_varchar_key` (`col_varchar_key`,`col_int_key`)
) ENGINE=InnoDB DEFAULT CHARSET=latin1;
INSERT INTO `CC` VALUES (3,8,'2008-12-04','00:00:00','v','v');
INSERT INTO `CC` VALUES (3,8,'2009-03-28','00:00:00','f','f');
INSERT INTO `CC` VALUES (3,5,'1900-01-01','00:55:47','v','v');
INSERT INTO `CC` VALUES (2,8,'2009-10-02','00:00:00','s','s');
INSERT INTO `CC` VALUES (1,8,'1900-01-01','20:51:59','a','a');
INSERT INTO `CC` VALUES (0,6,'2008-06-04','09:47:27','p','p');
INSERT INTO `CC` VALUES (8,7,'2009-01-13','21:58:29','z','z');
INSERT INTO `CC` VALUES (5,2,'1900-01-01','22:45:53','a','a');
INSERT INTO `CC` VALUES (9,5,'2008-01-28','14:06:48','h','h');
INSERT INTO `CC` VALUES (5,7,'2004-09-18','22:17:16','h','h');
INSERT INTO `CC` VALUES (4,2,'2006-10-14','14:59:37','v','v');
INSERT INTO `CC` VALUES (2,9,'1900-01-01','23:37:40','v','v');
INSERT INTO `CC` VALUES (33,142,'2000-11-28','14:14:01','b','b');
INSERT INTO `CC` VALUES (5,3,'2008-04-04','02:54:19','y','y');
INSERT INTO `CC` VALUES (1,0,'2002-07-13','06:34:26','v','v');
INSERT INTO `CC` VALUES (9,3,'2003-01-03','18:07:38','m','m');
INSERT INTO `CC` VALUES (1,5,'2006-04-02','13:55:23','z','z');
INSERT INTO `CC` VALUES (3,9,'2006-10-19','20:32:28','n','n');
INSERT INTO `CC` VALUES (8,1,'2005-06-08','11:57:44','d','d');
INSERT INTO `CC` VALUES (231,107,'2006-12-26','03:10:35','a','a');

SELECT table1 .`col_int_nokey` , table2 .`col_varchar_key` , table1 .`col_varchar_key` , table2 .`col_time_key` , table2 .`col_date_key` , table2 .`col_int_key`
FROM CC table1 STRAIGHT_JOIN ( CC table2 JOIN CC table3 ON table3 .`col_varchar_nokey` ) ON table2 .`col_int_nokey` AND table3 .`col_varchar_key` = table2 .`col_varchar_nokey`
ORDER BY table1 .`col_date_key`;

Changed in maria:
assignee: nobody → Igor Babaev (igorb-seattle)
milestone: none → 5.3
Revision history for this message
Philip Stoev (pstoev-askmonty) wrote :

Not reproducible with 5.3-main

Changed in maria:
importance: Undecided → Critical
status: New → Confirmed
status: Confirmed → In Progress
Changed in maria:
status: In Progress → Fix Committed
Changed in maria:
status: Fix Committed → Fix Released
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.