MySQL Bugs: #17405: Valgrind: conditional jump or move depends on unititialised values

Bug #17405	Valgrind: conditional jump or move depends on unititialised values
Submitted:	15 Feb 2006 1:45	Modified:	11 Apr 2006 5:30
Reporter:	Stewart Smith
Status:	Closed
Category:	Server: InnoDB	Severity:	S2 (Serious)
Version:	4.0, 4.1, 5.0.19 bk	OS:	Any (all)
Assigned to:	Marko Mäkelä	Target Version:

Description:
==32361== Thread 17:
==32361== Conditional jump or move depends on uninitialised value(s)
==32361==    at 0x849C289: buf_get_latched_pages_number (buf0buf.c:2184)
==32361==    by 0x844127E: srv_export_innodb_status (srv0srv.c:1806)
==32361==    by 0x82EB290: innodb_export_status() (ha_innodb.cc:6499)
==32361==    by 0x82CF143: ha_update_statistics() (handler.cc:1155)
==32361==    by 0x832A3BF: fill_status(THD*, st_table_list*, Item*) (sql_show.cc:3393)
==32361==    by 0x832B9F4: get_schema_tables_result(JOIN*) (sql_show.cc:3867)
==32361==    by 0x8264699: JOIN::exec() (sql_select.cc:1333)
==32361==    by 0x82660B3: mysql_select(THD*, Item***, st_table_list*, unsigned,
List<Item>&, Item*, unsigned, st_order*, st_order*, Item*, st_order*, unsigned long,
select_result*, st_select_lex_unit*, st_select_lex*) (sql_select.cc:1900)
==32361==    by 0x8266392: handle_select(THD*, st_lex*, select_result*, unsigned long)
(sql_select.cc:250)
==32361==    by 0x8204EFD: mysql_execute_command(THD*) (sql_parse.cc:2503)
==32361==    by 0x820D658: mysql_parse(THD*, char*, unsigned) (sql_parse.cc:5641)
==32361==    by 0x820E0BA: dispatch_command(enum_server_command, THD*, char*, unsigned)
(sql_parse.cc:1719)
==32361==
==32361== Conditional jump or move depends on uninitialised value(s)
==32361==    at 0x849C296: buf_get_latched_pages_number (buf0buf.c:2184)
==32361==    by 0x844127E: srv_export_innodb_status (srv0srv.c:1806)
==32361==    by 0x82EB290: innodb_export_status() (ha_innodb.cc:6499)
==32361==    by 0x82CF143: ha_update_statistics() (handler.cc:1155)
==32361==    by 0x832A3BF: fill_status(THD*, st_table_list*, Item*) (sql_show.cc:3393)
==32361==    by 0x832B9F4: get_schema_tables_result(JOIN*) (sql_show.cc:3867)
==32361==    by 0x8264699: JOIN::exec() (sql_select.cc:1333)
==32361==    by 0x82660B3: mysql_select(THD*, Item***, st_table_list*, unsigned,
List<Item>&, Item*, unsigned, st_order*, st_order*, Item*, st_order*, unsigned long,
select_result*, st_select_lex_unit*, st_select_lex*) (sql_select.cc:1900)
==32361==    by 0x8266392: handle_select(THD*, st_lex*, select_result*, unsigned long)
(sql_select.cc:250)
==32361==    by 0x8204EFD: mysql_execute_command(THD*) (sql_parse.cc:2503)
==32361==    by 0x820D658: mysql_parse(THD*, char*, unsigned) (sql_parse.cc:5641)
==32361==    by 0x820E0BA: dispatch_command(enum_server_command, THD*, char*, unsigned)
(sql_parse.cc:1719)

How to repeat:
start up ndb under valgrind
start up mysqld under valgrind
./mysql-test-run.pl --extern ndb_autodiscover

will get warnings.

Suggested fix:
don't have valgrind complain.

Assigning this to Marko.

Fix: in buf_block_init(), set:

block->buf_fix_count = 0;
block->io_fix = 0;
block->magic_n = 0;

Enough to fix this in 5.0 and 5.1.

Regards,

Heikki

/*************************************************************************
Returns the number of latched pages in the buffer pool. */

ulint
buf_get_latched_pages_number(void)
{
        buf_block_t* block;
        ulint i;
        ulint fixed_pages_number = 0;

        mutex_enter(&(buf_pool->mutex));

        for (i = 0; i < buf_pool->curr_size; i++) {

               block = buf_pool_get_nth_block(buf_pool, i);

               if (((block->buf_fix_count != 0) || (block->io_fix != 0)) &&
                    block->magic_n == BUF_BLOCK_MAGIC_N )
                       fixed_pages_number++;
        }

        mutex_exit(&(buf_pool->mutex));
        return fixed_pages_number;
}

I plugged this particular one with Heikki's directions. There still are similar cases,
which I'm working on:

==24960== Conditional jump or move depends on uninitialised value(s)
==24960==    at 0x83350E3: trx_sys_create_doublewrite_buf (trx0sys.c:198)
==24960==    by 0x82F2547: innobase_start_or_create_for_mysql (srv0start.c:1574)
==24960==    by 0x82E4E0B: innobase_init() (ha_innodb.cc:1433)
==24960==    by 0x8259F11: ha_initialize_handlerton(handlerton*) (handler.cc:414)
==24960==    by 0x8259F99: init_handlerton(THD*, st_plugin_int*, void*) (handler.cc:433)
==24960==    by 0x82E224E: plugin_foreach(THD*, char (*)(THD*, st_plugin_int*, void*),
int, void*) (sql_plugin.cc:891)
==24960==    by 0x825A1D3: ha_init() (handler.cc:450)
==24960==    by 0x8187336: init_server_components() (mysqld.cc:3284)
==24960==    by 0x818BA97: main (mysqld.cc:3623)

The patch suggested by Heikki has been committed to the InnoDB 5.0 and 5.1 source code
repositories.

Heikki says that eliminating uninitialized data in the first system tablespace pages
(such as FIL_PAGE_TYPE, FIL_PAGE_PREV, FIL_PAGE_NEXT) has low priority. Thus, the warning
about trx_sys_create_doublewrite_buf (trx0sys.c:198) testing uninitialized data and
warnings about InnoDB writing uninitialized data will remain for the time being.

Fixed in InnoDB snapshot368; fixes are in 5.0.20.

No changelog entry needed.