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

Server crashes when querying to wrong mysql.transaction_registry structure

Details

    Description

      --source include/have_innodb.inc
       
      CREATE TABLE t1 (x INT,start_trxid BIGINT UNSIGNED GENERATED ALWAYS AS ROW START,end_trxid BIGINT UNSIGNED GENERATED ALWAYS AS ROW END,PERIOD FOR SYSTEM_TIME(start_trxid,end_trxid)) ENGINE=INNODB WITH SYSTEM VERSIONING;
      INSERT INTO t1 (x) SELECT 1;
      CREATE OR REPLACE TABLE mysql.transaction_registry (id INT);
      INSERT INTO t1 (x) SELECT 1;
       
      #cleanup
      DROP TABLE t1;
      

      Leads to:

      CS 10.11.11 aa35f62f1c9b7cba0720d250a86294d686f8eb99 (Optimized)

      Core was generated by `/test/MD130125-mariadb-10.11.11-linux-x86_64-opt/bin/mariadbd --no-defaults --m'.
      Program terminated with signal SIGSEGV, Segmentation fault.
      #0  0x0000560f2d09ba4c in Field::store_timestamp (sec_part=<optimized out>, timestamp=1736835483, this=0x560f2e05ac58 <vtable for Field_long+16>)at /test/10.11_opt/sql/structs.h:1027
      [Current thread is 1 (Thread 0x151032123700 (LWP 2970679))]
      (gdb) bt
      #0  0x0000560f2d09ba4c in Field::store_timestamp (sec_part=<optimized out>, timestamp=1736835483, this=0x560f2e05ac58 <vtable for Field_long+16>) at /test/10.11_opt/sql/structs.h:1027
      #1  TR_table::store (this=this@entry=0x151032121660, field_id=field_id@entry=2, ts=<optimized out>) at /test/10.11_opt/sql/table.cc:10237
      #2  0x0000560f2d09bf6c in TR_table::update (this=this@entry=0x151032121660, start_id=29, end_id=end_id@entry=32) at /test/10.11_opt/sql/sql_class.h:4110
      #3  0x0000560f2d202a6a in ha_commit_trans (thd=thd@entry=0x15100c000c58, all=all@entry=false) at /test/10.11_opt/sql/handler.cc:1845
      #4  0x0000560f2d0d7693 in trans_commit_stmt (thd=thd@entry=0x15100c000c58) at /test/10.11_opt/sql/transaction.cc:501
      #5  0x0000560f2cfa500c in mysql_execute_command (thd=0x15100c000c58, is_called_from_prepared_stmt=<optimized out>) at /test/10.11_opt/sql/sql_parse.cc:6225
      #6  0x0000560f2cf94b85 in mysql_parse (rawbuf=<optimized out>, length=<optimized out>, parser_state=<optimized out>, thd=0x15100c000c58) at /test/10.11_opt/sql/sql_parse.cc:8188
      #7  mysql_parse (thd=0x15100c000c58, rawbuf=<optimized out>, length=<optimized out>, parser_state=<optimized out>) at /test/10.11_opt/sql/sql_parse.cc:8110
      #8  0x0000560f2cfa1782 in dispatch_command (command=COM_QUERY, thd=0x15100c000c58, packet=<optimized out>, packet_length=<optimized out>, blocking=<optimized out>) at /test/10.11_opt/sql/sql_class.h:1399
      #9  0x0000560f2cfa3799 in do_command (thd=thd@entry=0x15100c000c58, blocking=blocking@entry=true) at /test/10.11_opt/sql/sql_parse.cc:1419
      #10 0x0000560f2d0c6785 in do_handle_one_connection (connect=<optimized out>, connect@entry=0x560f3015db48, put_in_cache=put_in_cache@entry=true) at /test/10.11_opt/sql/sql_connect.cc:1386
      #11 0x0000560f2d0c6a8d in handle_one_connection (arg=0x560f3015db48) at /test/10.11_opt/sql/sql_connect.cc:1298
      #12 0x0000151052c3c609 in start_thread (arg=<optimized out>) at pthread_create.c:477
      #13 0x000015105280d133 in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:95
      

      CS 10.11.11 aa35f62f1c9b7cba0720d250a86294d686f8eb99 (Debug)

      Core was generated by `/test/MD130125-mariadb-10.11.11-linux-x86_64-dbg/bin/mariadbd --no-defaults --m'.
      Program terminated with signal SIGSEGV, Segmentation fault.
      #0  Field::store_timestamp (sec_part=102918, timestamp=1736833133, this=0x8f8f8f8f8f8f8f8f) at /test/10.11_dbg/sql/field.h:979
      [Current thread is 1 (Thread 0x147883ae7700 (LWP 347389))]
      (gdb) bt
      #0  Field::store_timestamp (sec_part=102918, timestamp=1736833133, this=0x8f8f8f8f8f8f8f8f) at /test/10.11_dbg/sql/field.h:979
      #1  TR_table::store (this=this@entry=0x147883ae5560, field_id=field_id@entry=2, ts={tv_sec = 1736833133, tv_usec = 102918}) at /test/10.11_dbg/sql/table.cc:10237
      #2  0x00005595fcc6ecf6 in TR_table::update (this=this@entry=0x147883ae5560, start_id=29, end_id=end_id@entry=32) at /test/10.11_dbg/sql/sql_class.h:4110
      #3  0x00005595fce314f1 in ha_commit_trans (thd=thd@entry=0x147870000d48, all=all@entry=false) at /test/10.11_dbg/sql/handler.cc:1845
      #4  0x00005595fccc01b3 in trans_commit_stmt (thd=thd@entry=0x147870000d48) at /test/10.11_dbg/sql/transaction.cc:501
      #5  0x00005595fcb4a099 in mysql_execute_command (thd=thd@entry=0x147870000d48, is_called_from_prepared_stmt=is_called_from_prepared_stmt@entry=false) at /test/10.11_dbg/sql/sql_parse.cc:6225
      #6  0x00005595fcb31329 in mysql_parse (thd=thd@entry=0x147870000d48, rawbuf=<optimized out>, length=<optimized out>, parser_state=parser_state@entry=0x147883ae6310) at /test/10.11_dbg/sql/sql_parse.cc:8188
      #7  0x00005595fcb3f483 in dispatch_command (command=command@entry=COM_QUERY, thd=thd@entry=0x147870000d48, packet=packet@entry=0x14787000af49 "INSERT INTO sv_t (x) SELECT 1", packet_length=packet_length@entry=29, blocking=blocking@entry=true) at /test/10.11_dbg/sql/sql_class.h:1399
      #8  0x00005595fcb41b9f in do_command (thd=thd@entry=0x147870000d48, blocking=blocking@entry=true) at /test/10.11_dbg/sql/sql_parse.cc:1419
      #9  0x00005595fccaadf1 in do_handle_one_connection (connect=<optimized out>, connect@entry=0x5595ff686ad8, put_in_cache=put_in_cache@entry=true) at /test/10.11_dbg/sql/sql_connect.cc:1386
      #10 0x00005595fccab2bf in handle_one_connection (arg=0x5595ff686ad8) at /test/10.11_dbg/sql/sql_connect.cc:1298
      #11 0x00001478b3e48609 in start_thread (arg=<optimized out>) at pthread_create.c:477
      #12 0x00001478b3a19133 in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:95
      

      Bug confirmed present in:
      MariaDB: 10.5.28 (dbg), 10.5.28 (opt), 10.6.21 (dbg), 10.6.21 (opt), 10.11.11 (dbg), 10.11.11 (opt), 11.4.5 (dbg), 11.4.5 (opt), 11.7.1 (dbg), 11.7.1 (opt), 11.8.0 (dbg), 11.8.0 (opt)

      Attachments

        Issue Links

          Activity

            I believe we shouldn't crash even if the TR table has lost some data

            nikitamalyavin Nikita Malyavin added a comment - I believe we shouldn't crash even if the TR table has lost some data

            People

              midenok Aleksey Midenkov
              ramesh Ramesh Sivaraman
              Votes:
              0 Vote for this issue
              Watchers:
              2 Start watching this issue

              Dates

                Created:
                Updated:

                Git Integration

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