Uploaded image for project: 'MariaDB Server'
  1. MariaDB Server
  2. MDEV-3395

LP:603026 - RQG: pagecache_read: Assertion `pageno < ((1ULL) << 40)' on OPTIMIZE TABLE of a Maria table

    Details

    • Type: Bug
    • Status: Closed
    • Priority: Major
    • Resolution: Fixed
    • Affects Version/s: None
    • Fix Version/s: None
    • Component/s: None
    • Labels:

      Description

      This bug was discovered previously in another scenario as MySQL Bug#42916.

      When executing OPTIMIZE TABLE after a kill -9 recovery, maria asserted as follows:

      mysqld: ma_pagecache.c:3279: pagecache_read: Assertion `pageno < ((1ULL) << 40)' failed.

      backtrace:

      #8 0x00133de8 in __assert_fail () from /lib/libc.so.6
      #9 0x08533d59 in pagecache_read (pagecache=0x9264d00, file=0xa5b2424, pageno=1814651154228852, level=3, buff=0x99a08ef0 "", type=PAGECACHE_LSN_PAGE,
      lock=PAGECACHE_LOCK_LEFT_UNLOCKED, page_link=0x99a08e80) at ma_pagecache.c:3279
      #10 0x085529fa in _ma_fetch_keypage (page=0x99a0af34, info=0xa5b6e78, keyinfo=0xa5b285c, pos=14865622255442755584, lock=PAGECACHE_LOCK_LEFT_UNLOCKED,
      level=3, buff=0x99a08ef0 "", return_buffer=0 '\000') at ma_page.c:108
      #11 0x08597291 in sort_one_index (param=0x99a0dde4, info=0xa5b6e78, keyinfo=0xa5b285c, pagepos=8589934595, new_file=41) at ma_check.c:3112
      #12 0x0859738a in sort_one_index (param=0x99a0dde4, info=0xa5b6e78, keyinfo=0xa5b285c, pagepos=616182317536301164, new_file=41) at ma_check.c:3132
      #13 0x08596d0d in maria_sort_index (param=0x99a0dde4, info=0xa5b6e78, name=0x99a0db17 "./test/table10000_maria_key_pk_parts_2_varchar_1024_not_null#P#p0")
      at ma_check.c:3006
      #14 0x0853c109 in ha_maria::repair (this=0xa5965f8, thd=0xa498878, param=0x99a0dde4, do_optimize=true) at ha_maria.cc:1486
      #15 0x0853b710 in ha_maria::optimize (this=0xa5965f8, thd=0xa498878, check_opt=0xa49a4e8) at ha_maria.cc:1365
      #16 0x083bee33 in handler::ha_optimize (this=0xa5965f8, thd=0xa498878, check_opt=0xa49a4e8) at handler.cc:3244
      #17 0x083c4d78 in handle_opt_part (thd=0xa498878, check_opt=0xa49a4e8, file=0xa5965f8, flag=1) at ha_partition.cc:963
      #18 0x083c52ee in ha_partition::handle_opt_partitions (this=0xa596160, thd=0xa498878, check_opt=0xa49a4e8, flag=1) at ha_partition.cc:1114
      #19 0x083c4b4a in ha_partition::optimize (this=0xa596160, thd=0xa498878, check_opt=0xa49a4e8) at ha_partition.cc:873
      #20 0x083bee33 in handler::ha_optimize (this=0xa596160, thd=0xa498878, check_opt=0xa49a4e8) at handler.cc:3244
      #21 0x083e3ad8 in mysql_admin_table (thd=0xa498878, tables=0xa57b478, check_opt=0xa49a4e8, operator_name=0x88943af "optimize", lock_type=TL_WRITE,
      open_for_modify=false, no_warnings_for_error=false, extra_open_options=0, prepare_func=0, operator_func=
      (int (handler::)(handler *, THD *, HA_CHECK_OPT *)) 0x83bee00 <handler::ha_optimize(THD, HA_CHECK_OPT*)>, view_operator_func=0) at sql_table.cc:4828
      #22 0x083e4df4 in mysql_optimize_table (thd=0xa498878, tables=0xa57b478, check_opt=0xa49a4e8) at sql_table.cc:5102
      #23 0x0828d634 in mysql_execute_command (thd=0xa498878) at sql_parse.cc:3118
      #24 0x08296857 in mysql_parse (thd=0xa498878, inBuf=0xa57b250 "OPTIMIZE TABLE `test`.`table10000_maria_key_pk_parts_2_varchar_1024_not_null`", length=77,
      found_semicolon=0x99a28228) at sql_parse.cc:6079
      #25 0x08288b11 in dispatch_command (command=COM_QUERY, thd=0xa498878, packet=0xa55b531 "", packet_length=77) at sql_parse.cc:1253
      #26 0x08287d4f in do_command (thd=0xa498878) at sql_parse.cc:891
      #27 0x08284e96 in handle_one_connection (arg=0xa498878) at sql_connect.cc:1599
      #28 0x00a08919 in start_thread () from /lib/libpthread.so.0
      #29 0x001ede5e in clone () from /lib/libc.so.6

      Before the OPTIMIZE TABLE, the table was checked with CHECK TABLE EXTENDED and ANALYZE TABLE. None reported a corruption when they probably should have.

      bzr version-info:

      revision-id: <email address hidden>
      date: 2010-06-14 15:17:54 +0400
      build-date: 2010-07-08 00:50:09 -0700
      revno: 2789
      branch-nick: maria

      The tablespace before recovery + core + binary will be uploaded shortly.

        Gliffy Diagrams

          Attachments

            Activity

            Hide
            philipstoev Philip Stoev added a comment -

            Core + binary + tablespaces before and after recovery
            LPexportBug603026_vardir-bug603026.zip

            Show
            philipstoev Philip Stoev added a comment - Core + binary + tablespaces before and after recovery LPexportBug603026_vardir-bug603026.zip
            Hide
            philipstoev Philip Stoev added a comment -

            Re: RQG: pagecache_read: Assertion `pageno < ((1ULL) << 40)' on OPTIMIZE TABLE after recovery of Maria engine

            Show
            philipstoev Philip Stoev added a comment - Re: RQG: pagecache_read: Assertion `pageno < ((1ULL) << 40)' on OPTIMIZE TABLE after recovery of Maria engine
            Hide
            philipstoev Philip Stoev added a comment -

            It turns out this bug is reproducible without recovery - just INSERT + OPTIMIZE

            Note that the table contains overly long indexes.
            Test case for bug 603026
            LPexportBug603026_mariabug603026.test

            Show
            philipstoev Philip Stoev added a comment - It turns out this bug is reproducible without recovery - just INSERT + OPTIMIZE Note that the table contains overly long indexes. Test case for bug 603026 LPexportBug603026_mariabug603026.test
            Hide
            philipstoev Philip Stoev added a comment -

            Re: RQG: pagecache_read: Assertion `pageno < ((1ULL) << 40)' on OPTIMIZE TABLE of a Maria table
            It turns out this bug is reproducible without recovery - just INSERT + OPTIMIZE

            Note that the table contains overly long indexes.

            Show
            philipstoev Philip Stoev added a comment - Re: RQG: pagecache_read: Assertion `pageno < ((1ULL) << 40)' on OPTIMIZE TABLE of a Maria table It turns out this bug is reproducible without recovery - just INSERT + OPTIMIZE Note that the table contains overly long indexes.
            Hide
            ratzpo Rasmus Johansson added a comment -

            Launchpad bug id: 603026

            Show
            ratzpo Rasmus Johansson added a comment - Launchpad bug id: 603026

              People

              • Assignee:
                monty Michael Widenius
                Reporter:
                philipstoev Philip Stoev
              • Votes:
                0 Vote for this issue
                Watchers:
                0 Start watching this issue

                Dates

                • Created:
                  Updated:
                  Resolved: