Bug #53306 valgrind: warnings in innodb.innodb

• Submitted: 30 Apr 2010 9:38
• Modified: 18 Oct 2010 19:37
• Reporter: Vasil Dimov
• Status: Closed
• Category: MySQL Server: InnoDB storage engine
• Severity: S3 (Non-critical)
• Version: mysql-5.1-innodb
• OS: Any
• Assigned to: Marko Mäkelä
• CPU Architecture: Any

[30 Apr 2010 9:38] Vasil Dimov

Description:
==26695== Syscall param pwrite64(buf) points to uninitialised byte(s)
==26695==    at 0x3A9A60E2E8: (within /lib64/libpthread-2.5.so)
==26695==    by 0x89CADA: os_file_write (os0file.c:2130)
==26695==    by 0x89E3E8: os_aio_simulated_handle (os0file.c:4190)
==26695==    by 0x86BE60: fil_aio_wait (fil0fil.c:4251)
==26695==    by 0x8CE4DB: io_handler_thread (srv0start.c:435)
==26695==    by 0x3A9A606616: start_thread (in /lib64/libpthread-2.5.so)
==26695==    by 0x3A99AD3C2C: clone (in /lib64/libc-2.5.so)
==26695==  Address 0x6C5C000 is 15,744 bytes inside a block of size 753,696 alloc'd
==26695==    at 0x4A05809: malloc (vg_replace_malloc.c:149)
==26695==    by 0x8E7E49: ut_malloc_low (ut0mem.c:82)
==26695==    by 0x89E345: os_aio_simulated_handle (os0file.c:4138)
==26695==    by 0x86BE60: fil_aio_wait (fil0fil.c:4251)
==26695==    by 0x8CE4DB: io_handler_thread (srv0start.c:435)
==26695==    by 0x3A9A606616: start_thread (in /lib64/libpthread-2.5.so)
==26695==    by 0x3A99AD3C2C: clone (in /lib64/libc-2.5.so)
==26695== Thread 9:
==26695== Syscall param pwrite64(buf) points to uninitialised byte(s)
==26695==    at 0x3A9A60E2E8: (within /lib64/libpthread-2.5.so)
==26695==    by 0x89CADA: os_file_write (os0file.c:2130)
==26695==    by 0x86C1BB: fil_io (fil0fil.c:4140)
==26695==    by 0x853B87: buf_flush_buffered_writes (buf0flu.c:293)
==26695==    by 0x8554BD: buf_flush_batch (buf0flu.c:958)
==26695==    by 0x8CE1C1: srv_master_thread (srv0srv.c:2632)
==26695==    by 0x3A9A606616: start_thread (in /lib64/libpthread-2.5.so)
==26695==    by 0x3A99AD3C2C: clone (in /lib64/libc-2.5.so)
==26695==  Address 0xAE4C000 is 4,048 bytes inside a block of size 2,113,568 alloc'd
==26695==    at 0x4A05809: malloc (vg_replace_malloc.c:149)
==26695==    by 0x8E7E49: ut_malloc_low (ut0mem.c:82)
==26695==    by 0x8DF0BC: trx_doublewrite_init (trx0sys.c:113)
==26695==    by 0x8DF9A8: trx_sys_create_doublewrite_buf (trx0sys.c:198)
==26695==    by 0x8CFE7C: innobase_start_or_create_for_mysql (srv0start.c:1619)
==26695==    by 0x835DB8: innobase_init(void*) (ha_innodb.cc:1971)
==26695==    by 0x731C4E: ha_initialize_handlerton(st_plugin_int*) (handler.cc:435)
==26695==    by 0x7D471C: plugin_initialize(st_plugin_int*) (sql_plugin.cc:1014)
==26695==    by 0x7D78BD: plugin_init(int*, char**, int) (sql_plugin.cc:1238)
==26695==    by 0x624B23: init_server_components() (mysqld.cc:3950)
==26695==    by 0x629374: main (mysqld.cc:4421)

How to repeat:
fetch mysql-5.1-innodb

$ ./configure --enable-thread-safe-client --enable-local-infile --with-pic --with-client-ldflags=-static --with-mysqld-ldflags=-static --with-zlib-dir=bundled --without-ndb-debug --with-big-tables --with-ssl --with-readline --with-embedded-server --with-archive-storage-engine --with-blackhole-storage-engine --with-csv-storage-engine --with-example-storage-engine --with-federated-storage-engine --with-partition --with-extra-charsets=all --with-innodb --with-ndbcluster --with-debug --prefix=/home/vdimov/mysql-5.1-innodb-install

[30 Apr 2010 9:39] Vasil Dimov

Full output from mtr

Attachment: innodb.innodb.valgrind.txt (text/plain), 4.47 KiB.

[4 May 2010 13:09] 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/107317

[4 May 2010 13:09] 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/107318

[4 May 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/107320

[4 May 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/107321

[4 May 2010 13: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/107322

[4 May 2010 13: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/107323

[4 May 2010 13:18] Marko Mäkelä

With added Valgrind instrumentation to places where blocks are inserted into the flush list and copied to the doublewrite buffer, I was able to determine that fsp_init_file_page_low() should initialize the pages to zero. (Alternatively, we could make sure that higher-level routines initialize all of the pages, but that could generate more redo log.)

[5 May 2010 11:32] Marko Mäkelä

Closed Bug #53009 as a duplicate of this.

[31 May 2010 8:28] Bugs System

Pushed into 5.1.48 (revid:[e-mail]-20100531082307-9x08gg1g7zybx2jy) (version source revid:[e-mail]-20100513074652-0cvlhgkesgbb2bfh) (merge vers: 5.5.5-m3) (pib:16)

[14 Jun 2010 5:58] Mark Callaghan

Does fsp_init_page_low() memset the entire page for correctness? Or just to avoid a valgrind warning? If this is done frequently, it is an expensive way to avoid a valgrind warning.

[14 Jun 2010 6:01] Mark Callaghan

Does fsp_init_page_low() memset the entire page for correctness? Or just to avoid a valgrind warning? If this is done frequently, it is an expensive way to avoid a valgrind warning.

[14 Jun 2010 8:10] Marko Mäkelä

Mark, you are right, this fix may hurt performance. I am not sure if this is a "genuine" bug. In any case, I think that it is a bad idea to write uninitialized bytes to data files.

An alternative fix would be to explicitly initialize the unused data in those places that need it. I decided against that, because it would generate more redo log. I thought that the MLOG_INIT_FILE_PAGE operation would be the logical place to initialize the whole page.

Come to think of it, there is a better solution: When applying the redo log entry of MLOG_INIT_FILE_PAGE, initialize the page. In other places, initialize only those bytes that would otherwise be left uninitialized, but do it outside the redo log mechanism.

[17 Jun 2010 6:13] Bugs System

Pushed into 5.5.5-m3 (revid:[e-mail]-20100615145247-8bj0vmuqlotbqsn9) (version source revid:[e-mail]-20100504130917-qmvzbj3pgil2nuat) (merge vers: 5.1.47) (pib:16)

[17 Jun 2010 6:17] Bugs System

Pushed into mysql-next-mr (revid:[e-mail]-20100615150216-cubqoyn1fj9b6a2p) (version source revid:[e-mail]-20100504130917-qmvzbj3pgil2nuat) (pib:16)

[22 Jun 2010 8:36] Marko Mäkelä

I reviewed the code once more. The function fsp_init_file_page() is internal to fsp0fsp.c. It is only called by code that creates file-based data structures for managing the allocated pages within the tablespace. That code should not be executed too often.

For a while, I thought that we could be initializing every new B-tree page twice, once in fsp_init_file_page() and then in page_create(). Something like that would certainly hurt performance.

We can reopen this bug if fsp_init_file_page() is showing high in a OProfile report, for example.

[27 Jul 2010 20:33] John Russell

Although there is some customer communication related to this bug, the specific fix appears to be primarily an internal issue. Closing without adding to Ref Man change log. (Please reopen if you feel it should be mentioned in the doc.)

[14 Oct 2010 8:38] Bugs System

Pushed into mysql-5.1-telco-7.0 5.1.51-ndb-7.0.20 (revid:[e-mail]-20101014082627-jrmy9xbfbtrebw3c) (version source revid:[e-mail]-20100513074652-0cvlhgkesgbb2bfh) (merge vers: 5.5.5-m3) (pib:21)

[14 Oct 2010 8:53] Bugs System

Pushed into mysql-5.1-telco-6.3 5.1.51-ndb-6.3.39 (revid:[e-mail]-20101014083757-5qo48b86d69zjvzj) (version source revid:[e-mail]-20100513074652-0cvlhgkesgbb2bfh) (merge vers: 5.5.5-m3) (pib:21)

[14 Oct 2010 9:08] Bugs System

Pushed into mysql-5.1-telco-6.2 5.1.51-ndb-6.2.19 (revid:[e-mail]-20101014084420-y54ecj85j5we27oa) (version source revid:[e-mail]-20100513074652-0cvlhgkesgbb2bfh) (merge vers: 5.5.5-m3) (pib:21)