| Bug #50888 | valgrind warnings in Field_timestamp::val_str | ||
|---|---|---|---|
| Submitted: | 3 Feb 2010 17:32 | Modified: | 11 Dec 2010 18:01 |
| Reporter: | Shane Bester (Platinum Quality Contributor) | Email Updates: | |
| Status: | Closed | Impact on me: | |
| Category: | MySQL Server: Data Types | Severity: | S2 (Serious) |
| Version: | 5.5.99-m3 | OS: | Any (fc6 x86) |
| Assigned to: | Tor Didriksen | CPU Architecture: | Any |
| Tags: | valgrind | ||
[3 Feb 2010 18:56]
Sveta Smirnova
I can not repeat on 64-bit Linux
[3 Feb 2010 19:41]
MySQL Verification Team
oops, i used a release binary, built using "./BUILD/compile-pentium-max"
[3 Feb 2010 21:27]
Sveta Smirnova
Thank you for the report. Please provide configure options you used to compile MySQL.
[8 Feb 2010 13:47]
MySQL Verification Team
Still repeatable. Exact steps, goto bzr directory: ./BUILD/compile-pentium-debug ./scripts/make_binary_distribution mv mysql-5.5.99-m3-linux-i686.tar.gz /tmp cd /tmp tar zxvf mysql-5.5.99-m3-linux-i686.tar.gz cd mysql-5.5.99-m3-linux-i686 mv ./libexec/* ./bin mv ./share/mysql/*.sql ./share ./scripts/mysql_install_db --no-defaults valgrind --tool=memcheck --track-origins=yes --leak-check=full --db-attach=yes -v --show-reachable=yes --num-callers=50 ./bin/mysqld --skip-grant-tables --skip-name-resolve --basedir=. --datadir=./data then login and run the testcase. My environment: revno: 2998 valgrind-3.5.0 Fedora Core release 6 (Zod) gcc (GCC) 4.1.1 20061011 (Red Hat 4.1.1-30) Linux box1.hti.co.za 2.6.18-1.2798.fc6xen #1 SMP Mon Oct 16 15:11:19 EDT 2006 i686 athlon i386 GNU/Linux
[8 Feb 2010 14:47]
Sveta Smirnova
Thank you for the feedback. Verified as described with valgrind start line provided.
[22 Feb 2010 14:42]
Manyi Lu
Sveta, does this bug occur on 5.1 and 6.0-bugfixing trees? Thanks, Manyi
[2 Mar 2010 7:44]
Tor Didriksen
to see the origin of the uninitialized value: ./mtr --valgrind-mysqld --valgrind-option='--track-origins=yes' ==16436== Conditional jump or move depends on uninitialised value(s) ==16436== at 0x6E0ECF: Field_timestamp::val_str(String*, String*) (field.cc:4921) ==16436== by 0x71CC25: Item_field::str_result(String*) (item.cc:2045) ==16436== by 0x72C3B7: Item_cache_str::cache_value() (item.cc:7463) ==16436== by 0x72C70F: Item_cache_str::val_str(String*) (item.cc:7513) ==16436== by 0x736736: Arg_comparator::can_compare_as_dates(Item*, Item*, unsigned long long*) (item_cmpfunc.cc:815) ==16436== by 0x736A3F: Arg_comparator::set_cmp_func(Item_result_field*, Item**, Item**, Item_result) (item_cmpfunc.cc:904) ==16436== by 0x5FEDB8: Arg_comparator::set_cmp_func(Item_result_field*, Item**, Item**, bool) (item_cmpfunc.h:82) ==16436== by 0x792DB1: Item_sum_hybrid::setup(Item*, Item*) (item_sum.cc:1220) ==16436== by 0x792B9A: Item_sum_hybrid::fix_fields(THD*, Item**) (item_sum.cc:1179) ==16436== by 0x55FFF3: setup_fields(THD*, Item**, List<Item>&, enum_mark_columns, List<Item>*, bool) (sql_base.cc:7522) ==16436== by 0x5D0329: JOIN::prepare(Item***, TABLE_LIST*, unsigned int, Item*, unsigned int, st_order*, st_order*, Item*, st_order*, st_select_lex*, st_select_lex_unit*) (sql_select.cc:498) ==16436== by 0x5D7577: 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:2459) ==16436== by 0x5CFBBB: handle_select(THD*, LEX*, select_result*, unsigned long) (sql_select.cc:271) ==16436== by 0x5AD120: execute_sqlcom_select(THD*, TABLE_LIST*) (sql_parse.cc:4562) ==16436== by 0x5A58B8: mysql_execute_command(THD*) (sql_parse.cc:2061) ==16436== by 0x5AF212: mysql_parse(THD*, char const*, unsigned int, char const**) (sql_parse.cc:5594) ==16436== Uninitialised value was created by a heap allocation ==16436== at 0x4A0515D: malloc (vg_replace_malloc.c:195) ==16436== by 0x9064A1: my_malloc (my_malloc.c:34) ==16436== by 0x8FBF7E: alloc_root (my_alloc.c:201) ==16436== by 0x51BD9C: Sql_alloc::operator new(unsigned long, st_mem_root*) (sql_list.h:45) ==16436== by 0x882164: myisam_create_handler(handlerton*, TABLE_SHARE*, st_mem_root*) (ha_myisam.cc:127) ==16436== by 0x70C080: get_new_handler(TABLE_SHARE*, st_mem_root*, handlerton*) (handler.cc:253) ==16436== by 0x65071E: open_table_from_share(THD*, TABLE_SHARE*, char const*, unsigned int, unsigned int, unsigned int, TABLE*, bool) (table.cc:1705) ==16436== by 0x55703C: open_table(THD*, TABLE_LIST*, st_mem_root*, Open_table_context*, unsigned int) (sql_base.cc:2858) ==16436== by 0x5596B5: open_and_process_table(THD*, LEX*, TABLE_LIST*, unsigned int*, unsigned int, Prelocking_strategy*, bool, Open_table_context*, st_mem_root*) (sql_base.cc:4192) ==16436== by 0x55A1CA: open_tables(THD*, TABLE_LIST**, unsigned int*, unsigned int, Prelocking_strategy*) (sql_base.cc:4591) ==16436== by 0x55B01B: open_and_lock_tables(THD*, TABLE_LIST*, bool, unsigned int, Prelocking_strategy*) (sql_base.cc:5185) ==16436== by 0x55058D: open_and_lock_tables(THD*, TABLE_LIST*, bool, unsigned int) (mysql_priv.h:1574) ==16436== by 0x5ACED3: execute_sqlcom_select(THD*, TABLE_LIST*) (sql_parse.cc:4527) ==16436== by 0x5A58B8: mysql_execute_command(THD*) (sql_parse.cc:2061) ==16436== by 0x5AF212: mysql_parse(THD*, char const*, unsigned int, char const**) (sql_parse.cc:5594) ==16436== by 0x5A32D9: dispatch_command(enum_server_command, THD*, char*, unsigned int) (sql_parse.cc:1024)
[5 Mar 2010 8:27]
Tor Didriksen
New test case:
CREATE TABLE t1(a timestamp) engine=myisam;
INSERT INTO t1 VALUES ('2008-02-23 09:23:45'), ('2010-03-05 11:08:02');
FLUSH TABLES t1;
SELECT MAX(a) FROM t1;
SELECT a FROM t1;
DROP TABLE t1;
With valgrind we get some warnings, and result:
SELECT MAX(a) FROM t1;
MAX(a)
2010-03-05 11:08:02
SELECT a FROM t1;
a
2008-02-23 09:23:45
2010-03-05 11:08:02
Without valgrind we get wrong result:
SELECT MAX(a) FROM t1;
MAX(a)
2008-02-23 09:23:45
SELECT a FROM t1;
a
2008-02-23 09:23:45
2010-03-05 11:08:02
[5 Mar 2010 8:30]
Tor Didriksen
We are calling Field::val_str() when we have table->status & STATUS_NO_RECORD so it is tempting to add an assert to catch this case. That is not possible however, since there is lots of manipulation of Field::ptr going on, so sometimes it will actually point to valid data even if no data is available from the underlying table.
[5 Mar 2010 9:13]
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/102411 3122 Tor Didriksen 2010-03-05 Bug#50888 valgrind warnings in Field_timestamp::val_str Ensure that we store the correct cached_field_type whenever we cache Field items (in this case it allows us to compare dates as dates, rather than strings) @ mysql-test/r/type_timestamp.result Add test case. @ mysql-test/t/type_timestamp.test Add test case. @ sql/item.h Initialize cached_field_type from the Field item.
[8 Mar 2010 14:34]
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/102587 3119 Tor Didriksen 2010-03-08 Bug#50888 valgrind warnings in Field_timestamp::val_str Ensure that we store the correct cached_field_type whenever we cache Field items (in this case it allows us to compare dates as dates, rather than strings) @ mysql-test/r/type_timestamp.result Add test case. @ mysql-test/t/type_timestamp.test Add test case. @ sql/item.h Initialize cached_field_type from the Field item.
[9 Mar 2010 14:55]
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/102726 3119 Tor Didriksen 2010-03-09 Bug#50888 valgrind warnings in Field_timestamp::val_str Ensure that we store the correct cached_field_type whenever we cache Field items (in this case it allows us to compare dates as dates, rather than strings) @ mysql-test/r/type_timestamp.result Add test case. @ mysql-test/t/type_timestamp.test Add test case. @ sql/item.h Initialize cached_field_type from the Field item.
[9 Mar 2010 15:47]
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/102746 3120 Tor Didriksen 2010-03-09 Bug#50888 valgrind warnings in Field_timestamp::val_str Ensure that we store the correct cached_field_type whenever we cache Field items (in this case it allows us to compare dates as dates, rather than strings) @ mysql-test/r/type_timestamp.result Add test case. @ mysql-test/t/type_timestamp.test Add test case. @ sql/item.h Initialize cached_field_type from the Field item.
[10 Mar 2010 7:13]
Alexander Nozdrin
Pushed into mysql-next-mr-bugfixing.
[10 Mar 2010 7:36]
Tor Didriksen
pushed to bzr+ssh://bk-internal.mysql.com/bzrroot/server/mysql-next-mr-bugfixing/ bzr+ssh://bk-internal.mysql.com/bzrroot/server/mysql-6.0-codebase-bugfixing/
[10 Mar 2010 13:37]
Bugs System
Pushed into 6.0.14-alpha (revid:alik@sun.com-20100310133305-0jdlngbtrkoqzckh) (version source revid:alik@sun.com-20100310132404-uqarl0o0vlra2kjx) (merge vers: 6.0.14-alpha) (pib:16)
[10 Mar 2010 13:38]
Bugs System
Pushed into 5.5.3-m3 (revid:alik@sun.com-20100310132634-zpyjzn346sgrm59u) (version source revid:alik@sun.com-20100310132634-zpyjzn346sgrm59u) (merge vers: 5.5.3-m3) (pib:16)
[10 Mar 2010 13:39]
Bugs System
Pushed into mysql-next-mr (revid:alik@sun.com-20100310132718-l0tegumhbg8umgjd) (version source revid:alik@sun.com-20100310132252-kpi29r22kjtl493x) (pib:16)
[15 Mar 2010 7:36]
Tor Didriksen
Aggregate functions on timestamp columns could yield wrong/undefined results.
[11 Dec 2010 18:01]
Paul DuBois
Noted in 5.5.3 changelog.
Description: Version: '5.5.99-m3' socket: '/tmp/mysql.sock' port: 3306 Source distribution Thread 3: Conditional jump or move depends on uninitialised value(s) at: Field_timestamp::val_str(String*, String*) (field.cc:4920) by: Item_field::str_result(String*) (item.cc:2045) by: Item_cache_str::cache_value() (item.cc:7463) by: Item_cache_str::val_str(String*) (item.cc:7513) by: Arg_comparator::can_compare_as_dates (item_cmpfunc.cc:815) by: Arg_comparator::set_cmp_func (item_cmpfunc.cc:904) by: Item_sum_hybrid::setup(Item*, Item*) (item_cmpfunc.h:82) by: Item_sum_hybrid::fix_fields(THD*, Item**) (item_sum.cc:1179) by: setup_fields (sql_base.cc:7353) by: JOIN::prepare (sql_select.cc:498) by: mysql_select (sql_select.cc:2445) by: handle_select (sql_select.cc:271) Uninitialised value was created by a heap allocation at: malloc (vg_replace_malloc.c:195) by: my_malloc (my_malloc.c:34) by: alloc_root (my_alloc.c:201) by: myisam_create_handler (sql_list.h:45) by: get_new_handler (handler.cc:252) by: open_table_from_share (table.cc:1678) by: open_unireg_entry (sql_base.cc:3949) by: open_table (sql_base.cc:2946) by: open_tables (sql_base.cc:4621) by: open_and_lock_tables_derived (sql_base.cc:5027) by: execute_sqlcom_select (mysql_priv.h:1575) by: mysql_execute_command(THD*) (sql_parse.cc:2139) field.cc:4920 is this: longget(temp,ptr); if (temp == 0L) <------ { I'm using revno: 2966 valgrind-3.5.0 Fedora Core release 6 (Zod) How to repeat: run mysqld under valgrind. login using mysql -uroot test -A drop table if exists `t1`; create table `t1`(`a` timestamp)engine=myisam; insert into `t1` values (0); flush tables; select max(`a`) from `t1`; Suggested fix: initialize all local variables in that and other functions.