Valgrind warning: Conditional jump or move depends on uninitialised value(s) in heap_scan (hp_scan.c:62 in mysql-55-eb

[Philip Stoev]

A stress test involving DDL over heap tables produced the following valgrind warning:

==13299== Thread 47:
==13299== Conditional jump or move depends on uninitialised value(s)
==13299== at 0x968096: heap_scan (hp_scan.c:62)
==13299== by 0x960BE8: ha_heap::rnd_next(unsigned char*) (ha_heap.cc:381)
==13299== by 0x85BF38: rr_sequential(READ_RECORD*) (records.cc:455)
==13299== by 0x69536A: mysql_update(THD*, TABLE_LIST*, List<Item>&, List<Item>&, Item*, unsigned int, st_order*, unsigned long long, enum_duplicates, bool, unsigned long long*, unsigned long long*) (sql_update.cc:644)
==13299== by 0x5F6F17: mysql_execute_command(THD*) (sql_parse.cc:2662)
==13299== by 0x5FED7A: mysql_parse(THD*, char*, unsigned int, Parser_state*) (sql_parse.cc:5503)
==13299== by 0x5F2CF4: dispatch_command(enum_server_command, THD*, char*, unsigned int) (sql_parse.cc:1034)
==13299== by 0x5F1F51: do_command(THD*) (sql_parse.cc:771)
==13299== by 0x6D7BEA: do_handle_one_connection(THD*) (sql_connect.cc:776)
==13299== by 0x6D7831: handle_one_connection (sql_connect.cc:724)
==13299== by 0x35A7207760: start_thread (in /lib64/libpthread-2.12.2.so)
==13299== by 0x1A7866FF: ???

bzr annotate shows that the line in question was modified by the patch:

  if (get_chunk_status(&share->recordspace, info->current_ptr) !=
      CHUNK_STATUS_ACTIVE)

[Philip Stoev (pstoev-askmonty)]

Another one in the same code:

==13299== Thread 38:
==13299== Invalid read of size 1
==13299== at 0x968091: heap_scan (hp_scan.c:62)
==13299== by 0x960BE8: ha_heap::rnd_next(unsigned char*) (ha_heap.cc:381)
==13299== by 0x85BF38: rr_sequential(READ_RECORD*) (records.cc:455)
==13299== by 0x69536A: mysql_update(THD*, TABLE_LIST*, List<Item>&, List<Item>&, Item*, unsigned int, st_order*, unsigned long long, enum_duplicates, bool, unsigned long long*, unsigned long long*) (sql_update.cc:644)
==13299== by 0x5F6F17: mysql_execute_command(THD*) (sql_parse.cc:2662)
==13299== by 0x5FED7A: mysql_parse(THD*, char*, unsigned int, Parser_state*) (sql_parse.cc:5503)
==13299== by 0x5F2CF4: dispatch_command(enum_server_command, THD*, char*, unsigned int) (sql_parse.cc:1034)
==13299== by 0x5F1F51: do_command(THD*) (sql_parse.cc:771)
==13299== by 0x6D7BEA: do_handle_one_connection(THD*) (sql_connect.cc:776)
==13299== by 0x6D7831: handle_one_connection (sql_connect.cc:724)
==13299== by 0x35A7207760: start_thread (in /lib64/libpthread-2.12.2.so)
==13299== by 0x1A53D6FF: ???

[Philip Stoev (pstoev-askmonty)]

Partially-simplified test case. May contain queries that are not relevant. Will produce other valgrind warings and/or crashes apart from the one mentioned in this bug.

[Laurynas Biveinis (laurynas-biveinis)]

What is the required schema for the bug783451.test?

[Philip Stoev (pstoev-askmonty)]

The test file itself contains the (randomly-generated) CREATE TABLE statements that are required to reproduce the bug.

To run the test case, please use --mysqld=--secure-file-priv=/path/to/randgen where /path/to/randgen is a directory obtained by running "bzr branch lp:randgen"

[Laurynas Biveinis (laurynas-biveinis)]

Thanks, now I'm able to run the bug783451.test workload. However, it does not produce any valgrind warnings (or other errors). Am I missing anything?

[Laurynas Biveinis (laurynas-biveinis)]

Have to fix paths in th bug783451.test workload.

[Philip Stoev (pstoev-askmonty)]

Sorry about that, I did not realize that paths are absolute.

[Laurynas Biveinis (laurynas-biveinis)]

Reduced testcase

[Laurynas Biveinis (laurynas-biveinis)]

The first valgrind error with the reduced testcase becomes

==3463== Thread 13:
==3463== Conditional jump or move depends on uninitialised value(s)
==3463== at 0x95B801: heap_scan (hp_scan.c:68)
==3463== by 0x9548BD: ha_heap::rnd_next(unsigned char*) (ha_heap.cc:381)
==3463== by 0x84E500: rr_sequential(READ_RECORD*) (records.cc:455)
==3463== by 0x66CEE5: mysql_update(THD*, TABLE_LIST*, List<Item>&, List<Item>&, Item*, unsigned int, st_order*, unsigned long long, enum_duplicates, bool, unsigned long long*
, unsigned long long*) (sql_update.cc:644)
==3463== by 0x5CE777: mysql_execute_command(THD*) (sql_parse.cc:2662)
==3463== by 0x5D68E2: mysql_parse(THD*, char*, unsigned int, Parser_state*) (sql_parse.cc:5503)
==3463== by 0x5CA532: dispatch_command(enum_server_command, THD*, char*, unsigned int) (sql_parse.cc:1034)
==3463== by 0x5C970C: do_command(THD*) (sql_parse.cc:771)
==3463== by 0x6B1182: do_handle_one_connection(THD*) (sql_connect.cc:776)
==3463== by 0x6B0D74: handle_one_connection (sql_connect.cc:724)
==3463== by 0x8E9BFE: pfs_spawn_thread (pfs.cc:1015)
==3463== by 0x4E35970: start_thread (pthread_create.c:304)
==3463== by 0x636192C: clone (clone.S:112)
==3463== Uninitialised value was created by a heap allocation
==3463== at 0x4C2815C: malloc (vg_replace_malloc.c:236)
==3463== by 0x8C83F1: my_malloc (my_malloc.c:38)
==3463== by 0x95CB28: hp_get_new_block (hp_block.c:79)
==3463== by 0x95C900: hp_find_free_hash (hp_write.c:369)
==3463== by 0x95C3A0: hp_write_key (hp_write.c:177)
==3463== by 0x95BFF8: heap_write (hp_write.c:63)
==3463== by 0x953FC4: ha_heap::write_row(unsigned char*) (ha_heap.cc:240)
==3463== by 0x746F5E: handler::ha_write_row(unsigned char*) (handler.cc:4781)
==3463== by 0x5B6BC1: write_record(THD*, TABLE*, st_copy_info*) (sql_insert.cc:1734)
==3463== by 0x5B4AC1: mysql_insert(THD*, TABLE_LIST*, List<Item>&, List<List<Item> >&, List<Item>&, List<Item>&, enum_duplicates, bool) (sql_insert.cc:928)
==3463== by 0x5CED55: mysql_execute_command(THD*) (sql_parse.cc:2787)
==3463== by 0x5D68E2: mysql_parse(THD*, char*, unsigned int, Parser_state*) (sql_parse.cc:5503)
==3463== by 0x5CA532: dispatch_command(enum_server_command, THD*, char*, unsigned int) (sql_parse.cc:1034)
==3463== by 0x5C970C: do_command(THD*) (sql_parse.cc:771)
==3463== by 0x6B1182: do_handle_one_connection(THD*) (sql_connect.cc:776)
==3463== by 0x6B0D74: handle_one_connection (sql_connect.cc:724)
==3463==

[Laurynas Biveinis (laurynas-biveinis)]

The line numbers are off due to added debugging code. The first part of the valgrind backtrace should have the same line numbers as in original report.