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

[2 Dec 2009 4:21] Shane Bester
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...
[2 Dec 2009 4:22] MySQL Verification Team
valgrind output from 5.1.41

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

[2 Dec 2009 4:25] MySQL Verification Team
5.0.87 is not affected
[2 Dec 2009 6:58] Valeriy Kravchuk
FYI, I can't repeat this with 5.1.42-debug under valgrind 3.5 on SuSE.
[2 Dec 2009 7:45] Sveta Smirnova
Thank you for the report.

Verified as described.
[19 Jan 2010 16:03] Georgi Kodinov
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)
...
[19 Jan 2010 16:11] Georgi Kodinov
bug.test

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

[21 Jan 2010 8:48] Bugs System
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).
[29 Jan 2010 15:05] Bugs System
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.
[5 Feb 2010 14:12] Bugs System
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.
[1 Mar 2010 8:46] Bugs System
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)
[2 Mar 2010 14:32] Bugs System
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)
[2 Mar 2010 14:37] Bugs System
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)
[2 Mar 2010 14:43] Bugs System
Pushed into mysql-next-mr (revid:alik@sun.com-20100302072432-k8xvfkgcggkwgi94) (version source revid:alik@sun.com-20100224135227-rcqs9pe9b2in80pf) (pib:16)
[9 Apr 2010 7:37] Martin Hansson
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.
[17 Jun 2010 12:07] Bugs System
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)
[17 Jun 2010 12:53] Bugs System
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)
[17 Jun 2010 13:34] Bugs System
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)
[8 Jul 2010 2:00] Paul Dubois
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.