| Bug #38999 | valgrind warnings for update statement in function compare_record() | ||
|---|---|---|---|
| Submitted: | 25 Aug 2008 9:17 | Modified: | 14 Oct 2010 13:41 |
| Reporter: | Shane Bester (Platinum Quality Contributor) | Email Updates: | |
| Status: | Closed | Impact on me: | |
| Category: | MySQL Server: DML | Severity: | S3 (Non-critical) |
| Version: | 5.0.44, 5.0.66a, 5.0.70, 5.0.74,5.0.76 | OS: | Linux |
| Assigned to: | Sergei Glukhov | CPU Architecture: | Any |
| Tags: | UPDATE, valgrind | ||
[25 Aug 2008 9:20]
MySQL Verification Team
uncut output of valgrind
Attachment: bug38999_valgrind_output.txt (text/plain), 2.90 KiB.
[2 Jan 2009 21:54]
MySQL Verification Team
still seeing this in 5.0.74: Thread 17: Conditional jump or move depends on uninitialised value(s) compare_record (sql_update.cc:34) mysql_update (sql_update.cc:472) mysql_execute_command (sql_parse.cc:3589) sp_instr_stmt::exec_core(sp_head.cc:2664) sp_lex_keeper::reset_lex_and_exec_core (sp_head.cc:2513) sp_instr_stmt::execute (sp_head.cc:2617) sp_head::execute (sp_head.cc:1130) sp_head::execute_procedure (sp_head.cc:1786) mysql_execute_command (sql_parse.cc:4788) mysql_parse (sql_parse.cc:6266) dispatch_command (sql_parse.cc:1938) handle_one_connection (sql_parse.cc:1628)
[5 Jan 2009 9:30]
MySQL Verification Team
specific testcase for 5.0.74: ----------------------------- Notice: I used this exact version: mysql-enterprise-gpl-5.0.74-linux-i686-glibc23.tar.gz firstly, start mysqld-debug or mysqld under valgrind: valgrind --tool=memcheck --leak-check=yes -v --show-reachable=yes ./bin/mysqld-debug --basedir=./ --datadir=./data --skip-grant-tables --skip-name-resolve Now run the following SQL: drop table if exists `t1`; create table `t1` (`a` tinyint,`b` tinyint,`c` tinyint,primary key (`a`)) engine=innodb; insert into `t1` set `a`=61,`b`=46,`c`=17; insert into `t1` set `a`=-46,`b`=-86,`c`=-93; insert into `t1` set `a`=0,`b`=-47,`c`=59; insert into `t1` set `a`=-115,`b`=74,`c`=-68; insert into `t1` set `a`=-98,`b`=8,`c`=-97; select 1 from `t1` where `b` = 112; update ignore `t1` set `a`=112 where `a` = '61';
[5 Jan 2009 10:21]
MySQL Verification Team
The above testcase also produces the valgrind warning on 5.0.76-debug bzr. Same testcase doesn't appear to affect 5.1.30, but some developer should check it.
[5 Jan 2009 10:24]
MySQL Verification Team
I'm using: glibc-2.5-3 valgrind-3.2.1 Fedora Core release 6 (Zod) Linux 2.6.18-1.2798.fc6xen #1 SMP Mon Oct 16 15:11:19 EDT 2006 i686 i686 i386 GNU/Linux
[5 May 2010 9:48]
Marko Mäkelä
I am seeing this after enabling some Valgrind diagnostics in mysql-5.1-innodb. The test case is a subset of innodb.test: -- source include/have_innodb.inc CREATE TABLE t1 (a int not null primary key, b int not null, key (b)) engine=innodb; CREATE TABLE t2 (a int not null primary key, b int not null, key (b)) engine=innodb; INSERT INTO t1 values (1,1),(2,2),(3,3),(4,4),(5,5),(6,6),(7,7),(8,8),(9,9),(10,10),(11,11),(12,12); INSERT INTO t2 values (1,1),(2,2),(3,3),(4,4),(5,5),(6,6),(7,7),(8,8),(9,9); select * from t1; # unique key update t1,t2 set t1.a=t1.a+100 where t1.a=1; drop table t1,t2;
[5 May 2010 9:53]
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/107437
[5 May 2010 9:53]
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/107438
[5 May 2010 9:54]
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/107439
[5 May 2010 9:54]
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/107440
[5 May 2010 10: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/107449
[5 May 2010 10: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/107450
[12 May 2010 11:21]
Marko Mäkelä
Note that because of this bug, I moved the test case from innodb.test to innodb_multi_update.test (disabled) in mysql-5.1-innodb.
[19 May 2010 7:48]
Vasil Dimov
This bug resurfaces after enabling UNIV_DEBUG_VALGRIND in storage/innobase/include/univ.i
main.ps_3innodb [ fail ] Found warnings/errors in server log file!
Test ended at 2010-05-15 11:13:54
line
==9838== Thread 11:
==9838== Conditional jump or move depends on uninitialised value(s)
==9838== at 0x75C5BD: compare_record(st_table*) (sql_update.cc:35)
==9838== by 0x744732: write_record(THD*, st_table*, st_copy_info*) (sql_insert.cc:1486)
==9838== by 0x74A0D7: mysql_insert(THD*, TABLE_LIST*, List<Item>&, List<List<Item> >&, List<Item>&, List<Item>&, enum_duplicates, bool) (sql_insert.cc:835)
==9838== by 0x6A79B4: mysql_execute_command(THD*) (sql_parse.cc:3198)
==9838== by 0x754998: Prepared_statement::execute(String*, bool) (sql_prepare.cc:3583)
==9838== by 0x754C4F: Prepared_statement::execute_loop(String*, bool, unsigned char*, unsigned char*) (sql_prepare.cc:3258)
==9838== by 0x754F33: mysql_sql_stmt_execute(THD*) (sql_prepare.cc:2529)
==9838== by 0x6A5028: mysql_execute_command(THD*) (sql_parse.cc:2272)
==9838== by 0x6ADAE8: mysql_parse(THD*, char const*, unsigned, char const**) (sql_parse.cc:5986)
==9838== by 0x6AF3A4: dispatch_command(enum_server_command, THD*, char*, unsigned) (sql_parse.cc:1233)
==9838== by 0x6B0800: do_command(THD*) (sql_parse.cc:874)
==9838== by 0x69CB46: handle_one_connection (sql_connect.cc:1134)
==9838== by 0x3895A06366: start_thread (in /lib64/libpthread-2.5.so)
==9838== by 0x3894ED30AC: clone (in /lib64/libc-2.5.so)
==9838== Conditional jump or move depends on uninitialised value(s)
==9838== at 0x75C5D0: compare_record(st_table*) (sql_update.cc:35)
==9838== by 0x744732: write_record(THD*, st_table*, st_copy_info*) (sql_insert.cc:1486)
==9838== by 0x74A0D7: mysql_insert(THD*, TABLE_LIST*, List<Item>&, List<List<Item> >&, List<Item>&, List<Item>&, enum_duplicates, bool) (sql_insert.cc:835)
==9838== by 0x6A79B4: mysql_execute_command(THD*) (sql_parse.cc:3198)
==9838== by 0x754998: Prepared_statement::execute(String*, bool) (sql_prepare.cc:3583)
==9838== by 0x754C4F: Prepared_statement::execute_loop(String*, bool, unsigned char*, unsigned char*) (sql_prepare.cc:3258)
==9838== by 0x754F33: mysql_sql_stmt_execute(THD*) (sql_prepare.cc:2529)
==9838== by 0x6A5028: mysql_execute_command(THD*) (sql_parse.cc:2272)
==9838== by 0x6ADAE8: mysql_parse(THD*, char const*, unsigned, char const**) (sql_parse.cc:5986)
==9838== by 0x6AF3A4: dispatch_command(enum_server_command, THD*, char*, unsigned) (sql_parse.cc:1233)
==9838== by 0x6B0800: do_command(THD*) (sql_parse.cc:874)
==9838== by 0x69CB46: handle_one_connection (sql_connect.cc:1134)
==9838== by 0x3895A06366: start_thread (in /lib64/libpthread-2.5.so)
==9838== by 0x3894ED30AC: clone (in /lib64/libc-2.5.so)
^ Found warnings in /export/home4/pb2/test/sb_2-1812509-1273904485.74/mysql-5.1.48-linux-x86_64-test/mysql-test/var-n_mix/log/mysqld.1.err
ok
[19 May 2010 8:00]
Vasil Dimov
The above can be reproduced with: ./mysql-test-run.pl --timer --force --parallel=auto --comment=n_mix --vardir=var-n_mix --mysqld=--binlog-format=mixed --experimental=collections/default.experimental --skip-ndb --valgrind --valgrind-options=--gen-suppressions=all --show-reachable=yes
[19 May 2010 8:39]
Marko Mäkelä
The SQL statement that triggers the failure in ps_3innodb.inc is execute stmt1 using @arg00, @arg01; in include/ps_modify.inc I ran the test on Debian GNU/Linux as follows: (cd mysql-test; ./mtr --manual-gdb --mem --suite main ps_3innodb) valgrind --db-attach=yes sql/mysqld "--defaults-group-suffix=.1" "--defaults-file=/home/marko/innobase/dev/mysql-5.1-innodb/mysql-test/var/my.cnf" "--log-output=file" "--gdb" "--loose-skip-log-bin" "--core-file" "--loose-debug-sync-timeout=300" I copied the command-line arguments for Valgrind from mysql-test/var/tmp/gdbinit.mysqld.1
[31 May 2010 8:29]
Bugs System
Pushed into 5.1.48 (revid:vasil.dimov@oracle.com-20100531082307-9x08gg1g7zybx2jy) (version source revid:vasil.dimov@oracle.com-20100531082307-9x08gg1g7zybx2jy) (merge vers: 5.1.48) (pib:16)
[8 Jun 2010 13:14]
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/110499 3420 Sergey Glukhov 2010-06-08 Bug#38999 valgrind warnings for update statement in function compare_record() Valgrind warning happpens because of uninitialized null bytes. In row_sel_push_cache_row_for_mysql() function we fill fetch cache with necessary field values, row_sel_store_mysql_rec() is called for this and leaves null bytes untouched. Later row_sel_pop_cached_row_for_mysql() rewrites table record buffer with uninited null bytes. We can see the problem from the test case: At 'SELECT...' we call row_sel_push...->row_sel_store...->row_sel_pop_cached... chain which rewrites table->record[0] buffer with uninitialized null bytes. When we call 'UPDATE...' statement, compare_record uses this buffer and valgrind warning occurs. The fix is to init null bytes with default values. @ mysql-test/r/innodb_mysql.result test case @ mysql-test/t/innodb_mysql.test test case @ mysql-test/t/ps_3innodb.test enable valgrind testing @ storage/innobase/row/row0sel.c init null bytes with default values as they might be left uninitialized in some cases and this uninited bytes might be copied into mysql record buffer that leads to valgrind warnings on next use of the buffer.
[9 Jun 2010 6:15]
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/110571 3420 Sergey Glukhov 2010-06-09 Bug#38999 valgrind warnings for update statement in function compare_record() Valgrind warning happpens because of uninitialized null bytes. In row_sel_push_cache_row_for_mysql() function we fill fetch cache with necessary field values, row_sel_store_mysql_rec() is called for this and leaves null bytes untouched. Later row_sel_pop_cached_row_for_mysql() rewrites table record buffer with uninited null bytes. We can see the problem from the test case: At 'SELECT...' we call row_sel_push...->row_sel_store...->row_sel_pop_cached... chain which rewrites table->record[0] buffer with uninitialized null bytes. When we call 'UPDATE...' statement, compare_record uses this buffer and valgrind warning occurs. The fix is to init null bytes with default values. @ mysql-test/r/innodb_mysql.result test case @ mysql-test/t/innodb_mysql.test test case @ mysql-test/t/ps_3innodb.test enable valgrind testing @ storage/innobase/row/row0sel.c init null bytes with default values as they might be left uninitialized in some cases and this uninited bytes might be copied into mysql record buffer that leads to valgrind warnings on next use of the buffer.
[9 Jun 2010 12:03]
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/110612 3505 Sergey Glukhov 2010-06-09 Bug#38999 valgrind warnings for update statement in function compare_record() Valgrind warning happpens because of uninitialized null bytes. In row_sel_push_cache_row_for_mysql() function we fill fetch cache with necessary field values, row_sel_store_mysql_rec() is called for this and leaves null bytes untouched. Later row_sel_pop_cached_row_for_mysql() rewrites table record buffer with uninited null bytes. We can see the problem from the test case: At 'SELECT...' we call row_sel_push...->row_sel_store...->row_sel_pop_cached... chain which rewrites table->record[0] buffer with uninitialized null bytes. When we call 'UPDATE...' statement, compare_record uses this buffer and valgrind warning occurs. The fix is to init null bytes with default values. @ mysql-test/suite/innodb/r/innodb_mysql.result test case @ mysql-test/suite/innodb/t/innodb_mysql.test test case @ mysql-test/suite/innodb_plugin/r/innodb_mysql.result test case @ mysql-test/suite/innodb_plugin/t/innodb_mysql.test test case @ mysql-test/t/ps_3innodb.test enable valgrind testing @ storage/innobase/row/row0sel.c init null bytes with default values as they might be left uninitialized in some cases and these uninited bytes might be copied into mysql record buffer that leads to valgrind warnings on next use of the buffer. @ storage/innodb_plugin/row/row0sel.c init null bytes with default values as they might be left uninitialized in some cases and these uninited bytes might be copied into mysql record buffer that leads to valgrind warnings on next use of the buffer.
[9 Jun 2010 12:06]
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/110613 3505 Sergey Glukhov 2010-06-09 Bug#38999 valgrind warnings for update statement in function compare_record() Valgrind warning happpens because of uninitialized null bytes. In row_sel_push_cache_row_for_mysql() function we fill fetch cache with necessary field values, row_sel_store_mysql_rec() is called for this and leaves null bytes untouched. Later row_sel_pop_cached_row_for_mysql() rewrites table record buffer with uninited null bytes. We can see the problem from the test case: At 'SELECT...' we call row_sel_push...->row_sel_store...->row_sel_pop_cached... chain which rewrites table->record[0] buffer with uninitialized null bytes. When we call 'UPDATE...' statement, compare_record uses this buffer and valgrind warning occurs. The fix is to init null bytes with default values. @ mysql-test/suite/innodb/r/innodb_mysql.result test case @ mysql-test/suite/innodb/t/innodb_mysql.test test case @ mysql-test/t/ps_3innodb.test enable valgrind testing @ storage/innobase/row/row0sel.c init null bytes with default values as they might be left uninitialized in some cases and these uninited bytes might be copied into mysql record buffer that leads to valgrind warnings on next use of the buffer.
[9 Jun 2010 12:16]
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/110615 3506 Sergey Glukhov 2010-06-09 Bug#38999 valgrind warnings for update statement in function compare_record() (InnoDB plugin branch) @ mysql-test/suite/innodb_plugin/r/innodb_mysql.result test case @ mysql-test/suite/innodb_plugin/t/innodb_mysql.test test case @ storage/innodb_plugin/row/row0sel.c init null bytes with default values as they might be left uninitialized in some cases and these uninited bytes might be copied into mysql record buffer that leads to valgrind warnings on next use of the buffer.
[9 Jun 2010 12:18]
Sergei Glukhov
pushed into mysql-5.1-innodb tree
[10 Jun 2010 12:57]
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/110717
[10 Jun 2010 12:57]
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/110718
[14 Jun 2010 6:35]
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/110962
[14 Jun 2010 6:35]
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/110963
[14 Jun 2010 6:50]
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/110964
[14 Jun 2010 6:51]
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/110965
[17 Jun 2010 6:14]
Bugs System
Pushed into 5.5.5-m3 (revid:alexey.kopytov@sun.com-20100615145247-8bj0vmuqlotbqsn9) (version source revid:vasil.dimov@oracle.com-20100520132735-a120y85kqmhp7hxi) (merge vers: 5.1.48) (pib:16)
[17 Jun 2010 6:17]
Bugs System
Pushed into mysql-next-mr (revid:alik@sun.com-20100615150216-cubqoyn1fj9b6a2p) (version source revid:vasil.dimov@oracle.com-20100520132735-a120y85kqmhp7hxi) (pib:16)
[7 Jul 2010 19:33]
Paul DuBois
Noted in 5.5.5 changelog. Valgrind warnings in the InnoDB compare_record() function were corrected. Setting report to Need Merge pending push to 5.1.x.
[19 Jul 2010 14:37]
Bugs System
Pushed into 5.1.49 (revid:build@mysql.com-20100719143034-omcma40sblwmay3x) (version source revid:vasil.dimov@oracle.com-20100704071244-3lo4okzels3kvy1p) (merge vers: 5.1.49) (pib:16)
[19 Jul 2010 19:29]
Paul DuBois
Noted in 5.1.49 changelog.
[23 Jul 2010 12:27]
Bugs System
Pushed into mysql-trunk 5.5.6-m3 (revid:alik@sun.com-20100723121820-jryu2fuw3pc53q9w) (version source revid:alik@sun.com-20100723121820-jryu2fuw3pc53q9w) (merge vers: 5.5.6-m3) (pib:18)
[23 Jul 2010 12:34]
Bugs System
Pushed into mysql-next-mr (revid:alik@sun.com-20100723121929-90e9zemk3jkr2ocy) (version source revid:alik@sun.com-20100723121827-3bsh51m5sj6g4oma) (pib:18)
[21 Sep 2010 8:59]
Marko Mäkelä
This bug fix was incorrect and introduced Bug #56423. The fix of Bug #56423 fixes the root cause and reverts the incorrect work-around.
[14 Oct 2010 8:37]
Bugs System
Pushed into mysql-5.1-telco-7.0 5.1.51-ndb-7.0.20 (revid:martin.skold@mysql.com-20101014082627-jrmy9xbfbtrebw3c) (version source revid:martin.skold@mysql.com-20101014082627-jrmy9xbfbtrebw3c) (merge vers: 5.1.51-ndb-7.0.20) (pib:21)
[14 Oct 2010 8:52]
Bugs System
Pushed into mysql-5.1-telco-6.3 5.1.51-ndb-6.3.39 (revid:martin.skold@mysql.com-20101014083757-5qo48b86d69zjvzj) (version source revid:martin.skold@mysql.com-20101014083757-5qo48b86d69zjvzj) (merge vers: 5.1.51-ndb-6.3.39) (pib:21)
[14 Oct 2010 9:07]
Bugs System
Pushed into mysql-5.1-telco-6.2 5.1.51-ndb-6.2.19 (revid:martin.skold@mysql.com-20101014084420-y54ecj85j5we27oa) (version source revid:martin.skold@mysql.com-20101014084420-y54ecj85j5we27oa) (merge vers: 5.1.51-ndb-6.2.19) (pib:21)
Description: ERROR SUMMARY: 76 errors from 5 contexts (suppressed: 23 from 1) 1 errors in context 1 of 5: Conditional jump or move depends on uninitialised value(s) : compare_record (sql_update.cc:32) : mysql_update (sql_update.cc:472) : mysql_execute_command : mysql_parse : dispatch_command : do_command : handle_one_connection Line 32 of sql_update.cc is this: bool compare_record(TABLE *table, query_id_t query_id) { if (table->s->blob_fields + table->s->varchar_fields == 0) return cmp_record(table,record[1]);<------------ /* Compare null bits */ if (memcmp(table->null_flags, How to repeat: will make a reduced testcase later