Details
-
Bug
-
Status: Closed (View Workflow)
-
Major
-
Resolution: Cannot Reproduce
-
10.5
-
None
-
BUILD/compile-pentium64-valgrind-max
Description
mtr --valgrind innodb.innodb_bug21704
==29405== Uninitialised byte(s) found during client check request
==29405== at 0x124891A: buf_flush_insert_into_flush_list(buf_pool_t*, buf_block_t*, unsigned long) (buf0flu.cc:434)
==29405== by 0x105F16C: buf_flush_note_modification(buf_block_t*, unsigned long, unsigned long, FlushObserver*) (buf0flu.ic:72)
==29405== by 0x1061DAD: ReleaseBlocks::add_dirty_page_to_flush_list(mtr_memo_slot_t*) const (mtr0mtr.cc:378)
==29405== by 0x1061DFC: ReleaseBlocks::operator()(mtr_memo_slot_t*) const (mtr0mtr.cc:390)
==29405== by 0x1062920: CIterate<ReleaseBlocks const>::operator()(mtr_buf_t::block_t*) const (mtr0mtr.cc:60)
==29405== by 0x106240D: bool mtr_buf_t::for_each_block_in_reverse<CIterate<ReleaseBlocks const> >(CIterate<ReleaseBlocks const> const&) const (dyn0buf.h:371)
==29405== by 0x10610C4: mtr_t::Command::release_blocks() (mtr0mtr.cc:882)
==29405== by 0x10611CD: mtr_t::Command::execute() (mtr0mtr.cc:910)
==29405== by 0x105FD75: mtr_t::commit() (mtr0mtr.cc:558)
==29405== by 0x118F2E8: trx_purge_truncate_rseg_history(trx_rseg_t&, purge_sys_t::iterator const&) (trx0purge.cc:493)
==29405== by 0x118F6D6: trx_purge_truncate_history() (trx0purge.cc:563)
==29405== by 0x1191D10: trx_purge(unsigned long, bool) (trx0purge.cc:1322)
==29405== by 0x116684B: srv_do_purge(unsigned long*) (srv0srv.cc:2623)
==29405== by 0x1166C82: srv_purge_coordinator_thread (srv0srv.cc:2749)
==29405== by 0x4E42568: start_thread (in /lib64/libpthread-2.26.so)
==29405== by 0x6ECBA2E: clone (in /lib64/libc-2.26.so)
==29405== Address 0x112e0434 is 1,076 bytes inside a frame of size 16,384 client-defined
==29405== at 0x1227BB3: buf_block_init(buf_pool_t*, buf_block_t*, unsigned char*) (buf0buf.cc:1511)
==29405== by 0x1228044: buf_chunk_init(buf_pool_t*, buf_chunk_t*, unsigned long) (buf0buf.cc:1657)
==29405== by 0x1228AE9: buf_pool_init_instance(buf_pool_t*, unsigned long, unsigned long) (buf0buf.cc:1891)
==29405== by 0x12294FD: buf_pool_init(unsigned long, unsigned long) (buf0buf.cc:2087)
==29405== by 0x116C476: srv_start(bool) (srv0start.cc:1512)
Attachments
Issue Links
- is part of
-
-
- Closed
-
- relates to
-
-
- Closed
-
Activity
I have a good reason to suspect that this is a duplicate of MDEV-20316. If the same server was running a test that used XA PREPARE, with no server restart in between, then the undo page flush related to the previous test would be reported for the current test.
If this kind of failure repeats with the MDEV-20316 fix present, please reopen, and try to include the full log.
Sorry, I cannot reproduce this on 10.2, 10.4, or 10.5. I would need more details, specifically, a run with vgdb, and showing the monitor get_vbits indicating which bits are supposedly uninitialized.
In my experience, Valgrind sometimes computes the V bits wrong (claiming that something is uninitialized when it actually is). A couple of years ago, I adjusted some bit operations in InnoDB debug assertions to avoid such false positives. There also were bogus warnings for some specific version of a SSL library, claiming that encrypted pages would contain uninitialized data when they in fact decrypted fine, and the source page (before encryption) was fine according to Valgrind. Yesterday when working on
MDEV-20316, I had to remove -O2 from my build options (I normally use it also with debug builds), because it would confuse Valgrind.