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

Crash when test_if_skip_sort_order() is checked for derived table subject to split

    XMLWordPrintable

    Details

      Description

      Partial stack trace:

      Thread 1 (Thread 0x7fbf90110700 (LWP 12354)):
      #0  0x00007fbf973e5aa1 in __pthread_kill (threadid=<optimized out>, signo=11) at ../nptl/sysdeps/unix/sysv/linux/pthread_kill.c:59
              __arg2 = 12354
              _a3 = 11
              _a1 = 12335
              resultvar = <optimized out>
              __arg3 = 11
              __arg1 = 12335
              _a2 = 12354
              pd = <optimized out>
              tid = 12354
              val = <optimized out>
      #1  0x0000556c5e03967e in handle_fatal_signal (sig=11) at /usr/src/debug/MariaDB-10.5.5/src_0/sql/signal_handler.cc:330
              curr_time = 1599787104
              tm = {tm_sec = 24, tm_min = 18, tm_hour = 1, tm_mday = 11, tm_mon = 8, tm_year = 120, tm_wday = 5, tm_yday = 254, tm_isdst = 0, tm_gmtoff = 0, tm_zone = 0x556c603ab540 "UTC"}
              thd = 0x7fbf58000da8
              print_invalid_query_pointer = false
      #2  <signal handler called>
      No locals.
      #3  row_search_mvcc (buf=<optimized out>, mode=PAGE_CUR_GE, prebuilt=0x7fbf582b3430, match_mode=<optimized out>, direction=0) at /usr/src/debug/MariaDB-10.5.5/src_0/storage/innobase/row/row0sel.cc:4747
              heap = 0x0
              set_also_gap_locks = <optimized out>
              err = DB_SUCCESS
              offsets_ = {300, 0 <repeats 23 times>, 65535, 65535, 65535, 32751, 0, 0, 0, 0, 2112, 22541, 32703, 0, 65535, 65535, 65535, 32751, 3496, 22528, 32703, 0, 65535, 65535, 65535, 32751, 0, 0, 0, 0, 65535, 65535, 65535, 32751, 0, 0, 0, 16368, 29576, 22541, 32703, 0, 65535, 65535, 65535, 32751, 0, 0, 0, 0, 14544, 22541, 32703, 0 <repeats 13 times>, 56416, 36880, 32703, 0, 14544, 22541, 32703, 0, 56320, 36880, 32703, 0, 16024, 22541, 0, 0, 0, 0, 0, 0, 0, 0, 21868, 0, 56512, 22572, 32703, 0, 65533, 65535, 65535, 32751, 0, 0, 0, 16404, 0, 0, 0, 0, 62243, 37008, 30037, 16600, 0, 0, 60416, 16557, 0, 0, 0, 0, 0, 0, 0, 0, 4353, 24303, 21868, 0, 1, 0 <repeats 11 times>, 513, 0, 0, 0, 4528, 24303, 21868, 0, 0, 0, 0, 0, 0, 0, 0, 0, 55809, 36880, 32703, 0, 56160, 36880, 32703, 0, 56160, 36880, 32703, 0, 14544, 22541, 32703, 0, 2, 0, 0, 0, 3, 0, 0, 0, 56512, 22572, 32703, 0, 15976, 22541, 32703, 0, 56768, 36880, 32703, 0, 58923, 24040, 21868, 0, 16024...}
              offsets = 0x7fbf9010d9b0
              index = 0x7fbf58069690
              clust_index = <optimized out>
              mtr_has_extra_clust_latch = 0
              moves_up = <optimized out>
              table_lock_waited = 0
              search_tuple = <optimized out>
              pcur = <optimized out>
              trx = 0x7fbf7d91c1c0
              rec = 0x0
              vrow = 0x0
              unique_search = <optimized out>
              same_user_rec = 140460732503440
              need_vrow = <optimized out>
              did_semi_consistent_read = false
              comp = 1
              clust_rec = 0x7fbf9010d600 "؍\016X\277\177"
              next_buf = 0x0
              spatial_search = <optimized out>
              mtr = {m_last = 0x0, m_last_offset = 0, m_log_mode = 0, m_modifications = 0, m_made_dirty = 0, m_inside_ibuf = 0, m_freed_in_system_tablespace = 0, m_trim_pages = 0, m_memo = {m_heap = 0x0, m_list = {<ilist<mtr_buf_t::block_t, void>> = {sentinel_ = {next = 0x7fbf9010dc48, prev = 0x7fbf9010dc48}}, size_ = 1}, m_size = 0, m_first_block = {<ilist_node<void>> = {next = 0x7fbf9010dc28, prev = 0x7fbf9010dc28}, m_data = "\200\215\062^lU\000\000 \336\020\220\277\177\000\000\022 3^lU\000\000\310\344\rX\277\177\000\000\060\064+X\277\177\000\000\060\064+X\277\177\000\000x\237\aX\277\177\000\000\300\334\020\220\277\177\000\000C\275\364]lU\000\000\300\344\rX\277\177\000\000 \347\rX\277\177\000\000\260f\000X\277\177\000\000*\353`^lU\000\000\000\335\020\220\277\177\000\000\272\355\364]lU\000\000@\263\rX\277\177\000\000`\240\rX\277\177\000\000\000\335\020\220\277\177\000\000\033\354\364]lU\000\000\200\253\rX\277\177\000\000`\240\rX\006\000\000\000\060\337\020\220\277\177\000\000\252\377\347]lU\000\000\060\335\020\220\277\177\000\000\b\343\rX\277\177\000\000"..., m_used = 0}}, m_log = {m_heap = 0x0, m_list = {<ilist<mtr_buf_t::block_t, void>> = {sentinel_ = {next = 0x7fbf9010de78, prev = 0x7fbf9010de78}}, size_ = 1}, m_size = 0, m_first_block = {<ilist_node<void>> = {next = 0x7fbf9010de58, prev = 0x7fbf9010de58}, m_data = "04+X\277\177\000\000\060\064+X\277\177\000\000x\237\aX\277\177\000\000\060\064+X\277\177\000\000\002\000\000\000\000\000\000\000\220\226\006X\277\177\000\000P\022+X\277\177\000\000\320\340\020\220\277\177\000\000\ngA^lU\000\000|\000\000\000\277\177\000\000\220e\006X\277\177\000\000\000\000\000\000\277\177\000\000\000\000\000\000\000\000\000\000\003\000\000\000\000\000\000\300\370\067+X\277\177\000\000\070\314\rX\277\177\000\000\f\000\000\000\000\000\000\000\360\065+X\277\177\000\000\001", '\000' <repeats 23 times>, "\070\314\rX\277\177\000\000\r\271\361]lU\000\000\020\341\020\220\277\177\000\000\200\215\062^lU\000\000"..., m_used = 0}}, m_user_space = 0x0, m_commit_lsn = 0, m_freed_pages = 0x0}
              result_rec = <optimized out>
              row_sel_get_clust_rec_for_mysql = {cached_clust_rec = 0x0, cached_old_vers = 0x0}
              next_offs = <optimized out>
      

      Part of query which crashes performs a JOIN of a real InnoDB table with a temporary table generated via CTE earlier in the query. The ON condition directly compares like columns from the real table to like columns from the temporary table with =. There are four such comparisons in the ON clause, joined together via AND logic.

      Note that removing any one of the comparisons from the ON conditional returns NULL and avoids a crash. Due to the nature of AND, we expect the result of all four conditions being evaluated to also be NULL. Database is crashing while attempting to evaluate a condition it does not need to return a valid result for the given query.

        Attachments

          Issue Links

            Activity

              People

              Assignee:
              psergei Sergei Petrunia
              Reporter:
              rob.schwyzer@mariadb.com Rob Schwyzer
              Votes:
              0 Vote for this issue
              Watchers:
              8 Start watching this issue

                Dates

                Created:
                Updated:
                Resolved: