MySQL Bugs: #49324: more valgrind errors in test_if_skip_sort

Bug #49324	more valgrind errors in test_if_skip_sort_order
Submitted:	2 Dec 2009 4:21	Modified:	8 Jul 2010 2:00
Reporter:	Shane Bester (Platinum Quality Contributor)	Email Updates:
Status:	Closed	Impact on me:	None
Category:	MySQL Server: Optimizer	Severity:	S1 (Critical)
Version:	5.1.41, 5.1, next-mr bzr	OS:	Any
Assigned to:	Georgi Kodinov	CPU Architecture:	Any
Tags:	regression, valgrind

Description:
at first, looks like bug #44886 but that testcase doesn't cause any problems anymore in 5.1.41

valgrind errors in 5.1.41:

Conditional jump or move depends on uninitialised value(s)
at: test_if_skip_sort_order  (sql_select.cc:13319)
by: JOIN::optimize() (sql_select.cc:1400)
by: mysql_select (sql_select.cc:2421)
by: handle_select (sql_select.cc:269)
by: execute_sqlcom_select (sql_parse.cc:5051)
by: mysql_execute_command(THD*) (sql_parse.cc:2246)
by: mysql_parse (sql_parse.cc:5970)
by: dispatch_command (sql_parse.cc:1231)
by: do_command(THD*) (sql_parse.cc:872)
by: handle_one_connection (sql_connect.cc:1127)
by: start_thread (in /lib/libpthread-2.5.so)
by: clone (in /lib/libc-2.5.so)

How to repeat:
run mysqld under valgrind, then run:

drop table if exists `t1`;
create table `t1` (`a` int primary key) engine=innodb ;
select 1 from `t1` join `t1` `a` using(`a`) group by `t1`.`a`,`t1`.`a`;

Suggested fix:
valgrind errors are bad...

valgrind output from 5.1.41

Attachment: bug49324_5.1.41_valgrind_output.txt (text/plain), 27.10 KiB.

5.0.87 is not affected

FYI, I can't repeat this with 5.1.42-debug under valgrind 3.5 on SuSE.

Thank you for the report.

Verified as described.

Tested with 5.1-bugteam with the attached test file and valgrind-3.5.0 on 64 bit Fedora 12.
Here's what I'm getting : 
==19581== Thread 11:
==19581== Invalid read of size 8
==19581==    at 0x7014DD: test_if_skip_sort_order(st_join_table*, st_order*, unsigned long long, bool, Bitmap<64u>*) (sql_select.cc:13314)
==19581==    by 0x6E0D6F: JOIN::optimize() (sql_select.cc:1410)
==19581==    by 0x6E4A62: mysql_select(THD*, Item***, TABLE_LIST*, unsigned int, List<Item>&, Item*, unsigned int, st_order*, st_order*, Item*, st_order*, unsigned long long, select_result*, st_select_lex_unit*, st_select_lex*) (sql_select.cc:2432)
...
==19581==  Address 0xb2e9008 is 0 bytes after a block of size 24 alloc'd
==19581==    at 0x4A0515D: malloc (vg_replace_malloc.c:195)
==19581==    by 0x9C90C7: my_malloc (my_malloc.c:34)
==19581==    by 0x9C9D02: alloc_root (my_alloc.c:158)
==19581==    by 0x6D094F: open_binary_frm(THD*, st_table_share*, unsigned char*, int) (table.cc:777)
==19581==    by 0x6CFFAA: open_table_def(THD*, st_table_share*, unsigned int) (table.cc:628)
...

bug.test

Attachment: bug.test (application/octet-stream, text), 206 bytes.

A patch for this bug has been committed. After review, it may
be pushed to the relevant source trees for release in the next
version. You can access the patch from:

  http://lists.mysql.com/commits/97697

3325 Georgi Kodinov	2010-01-21
      Bug #49324: more valgrind errors in test_if_skip_sort_order
      
      Fixed 2 problems :
      1. test_if_order_by_key() should not continue to the primary 
      key if already operating on it.
      2. The cost calculation should not try to read the records 
      per key when operating on ORDER BYs that order on all of the 
      secondary key + some of the primary key (as the information 
      is not available).

A patch for this bug has been committed. After review, it may
be pushed to the relevant source trees for release in the next
version. You can access the patch from:

  http://lists.mysql.com/commits/98652

3325 Georgi Kodinov	2010-01-29
      Bug #49324: more valgrind errors in test_if_skip_sort_order
      
      Fixed 2 problems :
      1. test_if_order_by_key() was continuing on the primary key
      as if it has a primary key suffix (as the secondary keys do).
      This leads to crashes in ORDER BY <pk>,<pk>.
      Fixed by not treating the primary key as the secondary one
      and not depending on it being clustered with a primary key.
      2. The cost calculation was trying to read the records 
      per key when operating on ORDER BYs that order on all of the 
      secondary key + some of the primary key.
      This leads to crashes because of out-of-bounds array access.
      Fixed by assuming we'll find 1 record per key in such cases.

A patch for this bug has been committed. After review, it may
be pushed to the relevant source trees for release in the next
version. You can access the patch from:

  http://lists.mysql.com/commits/99427

3366 Georgi Kodinov	2010-01-29
      Bug #49324: more valgrind errors in test_if_skip_sort_order
      
      Fixed 2 problems :
      1. test_if_order_by_key() was continuing on the primary key
      as if it has a primary key suffix (as the secondary keys do).
      This leads to crashes in ORDER BY <pk>,<pk>.
      Fixed by not treating the primary key as the secondary one
      and not depending on it being clustered with a primary key.
      2. The cost calculation was trying to read the records 
      per key when operating on ORDER BYs that order on all of the 
      secondary key + some of the primary key.
      This leads to crashes because of out-of-bounds array access.
      Fixed by assuming we'll find 1 record per key in such cases.

Pushed into 5.1.45 (revid:joro@sun.com-20100301083827-xnimmrjg6bh33o1o) (version source revid:joerg@mysql.com-20100212173307-ph563zr4wmoklgwd) (merge vers: 5.1.45) (pib:16)

Pushed into 6.0.14-alpha (revid:alik@sun.com-20100302142746-u1gxdf5yk2bjrq3e) (version source revid:alik@sun.com-20100225090938-2j5ybqoau570mytu) (merge vers: 6.0.14-alpha) (pib:16)

Pushed into 5.5.3-m2 (revid:alik@sun.com-20100302072233-t3uqgjzdukt1pyhe) (version source revid:alexey.kopytov@sun.com-20100209075938-mmcnyf6w631ozc45) (merge vers: 5.5.2-m2) (pib:16)

Pushed into mysql-next-mr (revid:alik@sun.com-20100302072432-k8xvfkgcggkwgi94) (version source revid:alik@sun.com-20100224135227-rcqs9pe9b2in80pf) (pib:16)

Paul:

Innodb stores secondary keys concatenated with the primary key's value. But primary keys are only stored as they are, hence the records are shorter for primary keys. But the test for using an index to do ORDER BY did not treat them differently, and expected the primary key value to be concatenated even to records that were the primary key already. I.e. it expected the primary key value to appear twice, and thus read into uninitialized memory.

Pushed into 5.1.47-ndb-7.0.16 (revid:martin.skold@mysql.com-20100617114014-bva0dy24yyd67697) (version source revid:vasil.dimov@oracle.com-20100331130613-8ja7n0vh36a80457) (merge vers: 5.1.46) (pib:16)

Pushed into 5.1.47-ndb-6.2.19 (revid:martin.skold@mysql.com-20100617115448-idrbic6gbki37h1c) (version source revid:martin.skold@mysql.com-20100609140708-52rvuyq4q500sxkq) (merge vers: 5.1.45-ndb-6.2.19) (pib:16)

Pushed into 5.1.47-ndb-6.3.35 (revid:martin.skold@mysql.com-20100617114611-61aqbb52j752y116) (version source revid:vasil.dimov@oracle.com-20100331130613-8ja7n0vh36a80457) (merge vers: 5.1.46) (pib:16)

Noted in 5.1.45, 5.5.3, 6.0.14 changelogs.

For InnoDB tables, the test for using an index for ORDER BY sorting
did not distinguish between primary keys and secondary indexes and
expected primary key values to be concatenated to index values the
way they are to secondary key values.