[MDEV-727] LP:625865 - ma_loghandler.c:3723: translog_init_with_table: Assertion `sure_page <= last_page' failed Created: 2010-08-28  Updated: 2020-10-18  Resolved: 2020-10-18

Status: Closed
Project: MariaDB Server
Component/s: Storage Engine - Aria
Affects Version/s: 5.5
Fix Version/s: N/A

Type: Bug Priority: Minor
Reporter: Philip Stoev (Inactive) Assignee: Unassigned
Resolution: Incomplete Votes: 0
Labels: Launchpad

Attachments: XML File LPexportBug625865.xml     Zip Archive LPexportBug625865_var-bug625865.zip     Text File assertion_failure_in_bb.txt    
Issue Links:
Duplicate
is duplicated by MDEV-18461 Aria crash recovery failures on the s... Stalled

 Description   

When executing recovery on the varchar RQG workload, aria 5.1 asserted as follows:

mysqld: ma_loghandler.c:3723: translog_init_with_table: Assertion `sure_page <= last_page' failed.

#8 0x00133d98 in __assert_fail () from /lib/libc.so.6
#9 0x084ff0fa in translog_init_with_table (directory=0x8a4b4c0 "/home/philips/bzr/maria-5.1/mysql-test/var/master-data_recovery/",
log_file_max_size=1073741824, server_version=50149, server_id=0, pagecache=0x9263600, flags=0, readonly=0 '\000',
init_table_func=0x84f69d0 <translog_table_init>, no_errors=0 '\000') at ma_loghandler.c:3723
#10 0x0851ecca in ha_maria_init (p=0xa4c9180) at ha_maria.cc:3259
#11 0x08397d21 in ha_initialize_handlerton (plugin=0xa4af810) at handler.cc:430
#12 0x08452e2f in plugin_initialize (plugin=0xa4af810) at sql_plugin.cc:1039
#13 0x08453651 in plugin_init (argc=0x8a4d318, argv=0xa47c870, flags=0) at sql_plugin.cc:1267
#14 0x0826c45b in init_server_components () at mysqld.cc:4131
#15 0x0826cf17 in main (argc=14, argv=0xbfe46754) at mysqld.cc:4603

rqg command line:

perl runall.pl --grammar=conf/engines/varchar.yy --gendata=conf/engines/varchar.zz --threads=1 --queries=10K --basedir=/home/philips/bzr/maria-5.1 --engine=Maria --debug --seed=time --engine=Maria --reporter=Recovery --duration=240 --threads=10

rqg version-info:

revision-id: philips@eve-20100828150416-gho2k908qs5ng4gx
date: 2010-08-28 18:04:16 +0300
build-date: 2010-08-28 18:10:03 +0300
revno: 506
branch-nick: randgen-bugfixing

maria version-info:

revision-id: <email address hidden>
date: 2010-08-25 01:43:26 +0300
build-date: 2010-08-28 18:10:15 +0300
revno: 2917
branch-nick: maria-5.1

 Comments   
Comment by Philip Stoev (Inactive) [ 2010-09-01 ]

Re: ma_loghandler.c:3723: translog_init_with_table: Assertion `sure_page <= last_page' failed

Comment by Philip Stoev (Inactive) [ 2010-09-01 ]

core binary datadir
LPexportBug625865_var-bug625865.zip

Comment by Rasmus Johansson (Inactive) [ 2011-09-05 ]

Launchpad bug id: 625865

Comment by Elena Stepanova [ 2012-10-31 ]

Could not reproduce on current maria/5.3. Assigning to myself to double-check other versions and close if not reproducible.

Comment by Elena Stepanova [ 2013-01-21 ]

As it can be seen from the attached logs, the problem started with the assertion failure which happened before the recovery:

mysqld: ma_page.c:430: _ma_new: Assertion `key_del_current != share->state.key_del && (key_del_current != 0) && ((key_del_current == (~ (my_off_t) 0)) || (key_del_current <= (share->state.state.key_file_length - block_size)))' failed.
100828 18:05:53 [ERROR] mysqld got signal 6 ;

A coredump was produced, then the test recognized the failure as a planned crash, started recovery, and apparently ran out of space while copying the datadir for the recovery.
Running out of space is my guess since we don't have the test output, but the whole sequence of events is reproducible on binaries of that time (I'm using maria/5.1 revno 2919): I run the stress test as described, sporadically get the assertion failure in _ma_new, and if I don't have much space on the disk, the test fails to copy all files needed for recovery, including aria logs, attempts the recovery nevertheless, and fails with the exact assertion failure described in this bug report.

For this second assertion in ma_loghandler.c on recovery, I suppose not much can be done, if the recovery information is really missing or corrupted as we could see in bug MDEV-583, which describes the same failure.

For the assertion in _ma_new, there was another bug report MDEV-3711. As Monty wrote in a comment to that report, he tried to reproduce it later and couldn't, so apparently it was fixed. I've got the same results, also tried multiple times and never had the failure, while on the old build (same build type, same machine, same test, just old sources) it happens quite frequently.

So, I'm closing it as a duplicate of MDEV-3711 which, in turn, was earlier closed as fixed.

Comment by Elena Stepanova [ 2013-08-08 ]

A similar issue was observed on MariaDB 5.5 revno 3848, revision-Id: bar@mariadb.org-20130808094121-cqmjldq0lh2bhl3m. The output is attached (assertion_failure_in_bb.txt)

Comment by Elena Stepanova [ 2020-10-18 ]

It will be further tracked in MDEV-18461. It also doesn't have a test case so far, but the full more recent dataset, coredump etc.

Generated at Thu Feb 08 06:30:53 UTC 2024 using Jira 8.20.16#820016-sha1:9d11dbea5f4be3d4cc21f03a88dd11d8c8687422.