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

Under Windows Subsystem for Linux, InnoDB crashes on ALTER TABLE or OPTIMIZE TABLE

Details

    Description

      creating empty table plus primary or unique key forces shutdown+recovery from official docker-image.

      db-1       | 2024-09-16 11:00:19 487 [ERROR] InnoDB: preallocating 81920 bytes for file ./mountedoutside/user.ibd failed with error 2
      db-1       | 2024-09-16 11:00:19 0x7f9c203f3640  InnoDB: Assertion failure in file /home/buildbot/amd64-rhel-9-rpm-autobake/build/padding_for_CPACK_RPM_BUILD_SOURCE_DIRS_PREFIX/storage/innobase/fil/fil0fil.cc line 629
      db-1       | InnoDB: Failing assertion: fsize != os_offset_t(-1)
      db-1       | InnoDB: We intentionally generate a memory trap.
      db-1       | InnoDB: Submit a detailed bug report to https://jira.mariadb.org/
      db-1       | InnoDB: If you get repeated assertion failures or crashes, even
      db-1       | InnoDB: immediately after the mariadbd startup, there may be
      db-1       | InnoDB: corruption in the InnoDB tablespace. Please refer to
      db-1       | InnoDB: https://mariadb.com/kb/en/library/innodb-recovery-modes/
      db-1       | InnoDB: about forcing recovery.
      db-1       | 240916 11:00:19 [ERROR] mysqld got signal 6 ;
      db-1       | Sorry, we probably made a mistake, and this is a bug.
      db-1       | To report this bug, see https://mariadb.com/kb/en/reporting-bugs
      db-1       |
      db-1       | We will try our best to scrape up some info that will hopefully help
      db-1       | diagnose the problem, but since we have already crashed,
      db-1       | something is definitely wrong and this may fail.
      db-1       |
      db-1       | Server version: 11.4.3-MariaDB source revision: 5ab81ffe0097a22a774957df28c5223cf0201de3
      db-1       | key_buffer_size=134217728
      db-1       | read_buffer_size=131072
      db-1       | max_used_connections=10
      db-1       | max_threads=153
      db-1       | thread_count=10
      db-1       | It is possible that mysqld could use up to
      db-1       | key_buffer_size + (read_buffer_size + sort_buffer_size)*max_threads = 468068 K  bytes of memory
      db-1       | Hope that's ok; if not, decrease some variables in the equation.
      db-1       |
      db-1       | Thread pointer: 0x7f9bfc000c58
      db-1       | Attempting backtrace. You can use the following information to find out
      db-1       | where mysqld died. If you see no messages after this, something went
      db-1       | terribly wrong...
      db-1       | stack_bottom = 0x7f9c203f2cb8 thread_stack 0x49000
      db-1       | Printing to addr2line failed
      db-1       | mariadbd(my_print_stacktrace+0x2e)[0x5572f258767e]
      db-1       | mariadbd(handle_fatal_signal+0x478)[0x5572f2051168]
      db-1       | /lib64/libc.so.6(+0x3e6f0)[0x7f9c438046f0]
      db-1       | /lib64/libc.so.6(+0x8b94c)[0x7f9c4385194c]
      db-1       | /lib64/libc.so.6(raise+0x16)[0x7f9c43804646]
      db-1       | /lib64/libc.so.6(abort+0xd3)[0x7f9c437ee7f3]
      db-1       | mariadbd(+0x6e4678)[0x5572f1c44678]
      db-1       | mariadbd(+0x6f41d4)[0x5572f1c541d4]
      db-1       | mariadbd(+0x6f53bf)[0x5572f1c553bf]
      db-1       | mariadbd(+0x6f794b)[0x5572f1c5794b]
      db-1       | mariadbd(+0x6f8273)[0x5572f1c58273]
      db-1       | mariadbd(+0xf78768)[0x5572f24d8768]
      db-1       | mariadbd(+0xf7987c)[0x5572f24d987c]
      db-1       | mariadbd(+0xefaeaa)[0x5572f245aeaa]
      db-1       | mariadbd(+0xf3b523)[0x5572f249b523]
      db-1       | mariadbd(+0xf3bdd7)[0x5572f249bdd7]
      db-1       | mariadbd(+0xe72f21)[0x5572f23d2f21]
      db-1       | mariadbd(+0xdfca4e)[0x5572f235ca4e]
      db-1       | mariadbd(+0xe04f5b)[0x5572f2364f5b]
      db-1       | mariadbd(+0xe08024)[0x5572f2368024]
      db-1       | mariadbd(_Z17mysql_alter_tableP3THDPK25st_mysql_const_lex_stringS3_P22Table_specification_stP10TABLE_LISTP13Recreate_infoP10Alter_infojP8st_orderbb+0x5493)[0x5572f1e95e63]
      db-1       | mariadbd(_ZN19Sql_cmd_alter_table7executeEP3THD+0x3fb)[0x5572f1f036cb]
      db-1       | mariadbd(_Z21mysql_execute_commandP3THDb+0x4684)[0x5572f1dcd694]
      db-1       | mariadbd(_Z11mysql_parseP3THDPcjP12Parser_state+0x1e7)[0x5572f1dce797]
      db-1       | mariadbd(_Z16dispatch_command19enum_server_commandP3THDPcjb+0xee5)[0x5572f1dd0985]
      db-1       | mariadbd(_Z10do_commandP3THDb+0x134)[0x5572f1dd2e94]
      db-1       | mariadbd(_Z24do_handle_one_connectionP7CONNECTb+0x3bf)[0x5572f1efe61f]
      db-1       | mariadbd(handle_one_connection+0x5d)[0x5572f1efe96d]
      db-1       | mariadbd(+0xd2cbb2)[0x5572f228cbb2]
      db-1       | /lib64/libc.so.6(+0x89c02)[0x7f9c4384fc02]
      db-1       | /lib64/libc.so.6(+0x10ec40)[0x7f9c438d4c40]
      db-1       |
      db-1       | Trying to get some variables.
      db-1       | Some pointers may be invalid and cause the dump to abort.
      db-1       | Query (0x7f9bfc010b70): alter table user
      db-1       |   add constraint user_name_unique
      db-1       |     unique (name)
      db-1       |
      db-1       | Connection ID (thread ID): 487
      db-1       | Status: NOT_KILLED
      db-1       |
      db-1       | Optimizer switch: index_merge=on,index_merge_union=on,index_merge_sort_union=on,index_merge_intersection=on,index_merge_sort_intersection=off,index_condition_pushdown=on,derived_merge=on,derived_with_keys=on,firstmatch=on,loosescan=on,materialization=on,in_to_exists=on,semijoin=on,partial_match_rowid_merge=on,partial_match_table_scan=on,subquery_cache=on,mrr=off,mrr_cost_based=off,mrr_sort_keys=off,outer_join_with_cache=on,semijoin_with_cache=on,join_cache_incremental=on,join_cache_hashed=on,join_cache_bka=on,optimize_join_buffer_size=on,table_elimination=on,extended_keys=on,exists_to_in=on,orderby_uses_equalities=on,condition_pushdown_for_derived=on,split_materialized=on,condition_pushdown_for_subquery=on,rowid_filter=on,condition_pushdown_from_having=on,not_null_range_scan=off,hash_join_cardinality=on,cset_narrowing=off,sargable_casefold=on
      
      

      issuing

      create table if not exists operator (
                                        id int not null,
                                        name varchar(64) not null,
        idpid varchar(128) not null
        ) engine=innodb default charset=utf8mb4 collate utf8mb4_bin;
       
      alter table operator
        add constraint operator_id_pk
          primary key (id);
       
      alter table operator
        add constraint operator_name_unique
          unique (name);
       
      alter table operator
        add constraint operator_idpid_unique
          unique (idpid);
      

      This is mostly to document that the linked issue is also reproducible in a newer version. The three constraints order is arbitrary - it is always the first that fails.

      Attachments

        Issue Links

          Activity

            My fix is to replace many fstat() calls with calls to os_file_get_size(), which invokes lseek() or SetFilePointerEx(). Some fstat() calls remain, because they are querying also other attributes than stat::st_size. To my understanding, those remaining calls should not be invoked after the file name with which the file handle had been opened had been renamed.

            marko Marko Mäkelä added a comment - My fix is to replace many fstat() calls with calls to os_file_get_size() , which invokes lseek() or SetFilePointerEx() . Some fstat() calls remain, because they are querying also other attributes than stat::st_size . To my understanding, those remaining calls should not be invoked after the file name with which the file handle had been opened had been renamed.

            Yes, it replaces fstat() with seek().

            Yes it works around the problem (supposedly — just a guess — fstat() is implemented there as "get the file name (that was stored in the open-file-structure when the file was opened), run stat()" which fails when the file was renamed meanwhile).

            And yes, I think it should be applied to the earliest maintained version.

            serg Sergei Golubchik added a comment - Yes, it replaces fstat() with seek() . Yes it works around the problem (supposedly — just a guess — fstat() is implemented there as "get the file name (that was stored in the open-file-structure when the file was opened), run stat() " which fails when the file was renamed meanwhile). And yes, I think it should be applied to the earliest maintained version.

            As far as I understand, the proposed fix would replace fstat() with my_seek(), to determine the file size. If this works around a problem when using Windows Subsystem for Linux as a container host, that looks fine to me. But should it be applied to the earliest maintained version?

            marko Marko Mäkelä added a comment - As far as I understand, the proposed fix would replace fstat() with my_seek() , to determine the file size. If this works around a problem when using Windows Subsystem for Linux as a container host, that looks fine to me. But should it be applied to the earliest maintained version?
            Buhl Jesper Buhl added a comment - - edited

            Here's a nice one:

            I removed

               volumes:
                  - ../../data/mariadb:/var/lib/mysql
            

            (i.e. rhel inside win)

            from our docker-compose.yaml and now fail to crash it.

            Buhl Jesper Buhl added a comment - - edited Here's a nice one: I removed volumes: - ../../data/mariadb:/var/lib/mysql (i.e. rhel inside win) from our docker-compose.yaml and now fail to crash it.

            People

              marko Marko Mäkelä
              Buhl Jesper Buhl
              Votes:
              0 Vote for this issue
              Watchers:
              5 Start watching this issue

              Dates

                Created:
                Updated:
                Resolved:

                Git Integration

                  Error rendering 'com.xiplink.jira.git.jira_git_plugin:git-issue-webpanel'. Please contact your Jira administrators.