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

Killing a query inside InnoDB causes it crash

    XMLWordPrintable

Details

    • Bug
    • Status: Closed (View Workflow)
    • Critical
    • Resolution: Fixed
    • None
    • N/A
    • None
    • None
    • CentOS release 6.3 (Final) 2.6.32-279.el6.x86_64

      5.5.31-MariaDB-log

    Description

      140421 10:07:23  InnoDB: Assertion failure in thread 47429123118848 in file btr0pcur.c line 254
      InnoDB: We intentionally generate a memory trap.
      InnoDB: Submit a detailed bug report to http://bugs.mysql.com.
      InnoDB: If you get repeated assertion failures or crashes, even
      InnoDB: immediately after the mysqld startup, there may be
      InnoDB: corruption in the InnoDB tablespace. Please refer to
      InnoDB: http://dev.mysql.com/doc/refman/5.5/en/forcing-innodb-recovery.html
      InnoDB: about forcing recovery.
      140421 10:07:23 [ERROR] mysqld got signal 6 ;
      This could be because you hit a bug. It is also possible that this binary
      or one of the libraries it was linked against is corrupt, improperly built,
      or misconfigured. This error can also be caused by malfunctioning hardware.
       
      To report this bug, see http://kb.askmonty.org/en/reporting-bugs
       
      We will try our best to scrape up some info that will hopefully help
      diagnose the problem, but since we have already crashed, 
      something is definitely wrong and this may fail.
       
      Server version: 5.5.31-MariaDB-log
      key_buffer_size=2147483648
      read_buffer_size=4194304
      max_used_connections=60
      max_threads=3002
      thread_count=43
      It is possible that mysqld could use up to 
      key_buffer_size + (read_buffer_size + sort_buffer_size)*max_threads = 39039253 K  bytes of memory
      Hope that's ok; if not, decrease some variables in the equation.
       
      Thread pointer: 0x0x8a80f920
      Attempting backtrace. You can use the following information to find out
      where mysqld died. If you see no messages after this, something went
      terribly wrong...
      stack_bottom = 0x2b22f4090e20 thread_stack 0x48000
      (my_addr_resolve failure: fork)
      /apps/svr/mariadb5/bin/mysqld(my_print_stacktrace+0x2e) [0xb059fe]
      /apps/svr/mariadb5/bin/mysqld(handle_fatal_signal+0x422) [0x6eb552]
      /lib64/libpthread.so.0() [0x348bc0f500]
      /lib64/libc.so.6(gsignal+0x35) [0x348b8328a5]
      /lib64/libc.so.6(abort+0x175) [0x348b834085]
      /apps/svr/mariadb5/bin/mysqld() [0x8da6cb]
      /apps/svr/mariadb5/bin/mysqld() [0x886ce4]
      /apps/svr/mariadb5/bin/mysqld() [0x88b2bd]
      /apps/svr/mariadb5/bin/mysqld() [0x85aea1]
      /apps/svr/mariadb5/bin/mysqld(handler::read_range_next()+0xf3) [0x6efee3]
      /apps/svr/mariadb5/bin/mysqld(handler::multi_range_read_next(void**)+0xd2) [0x682ad2]
      /apps/svr/mariadb5/bin/mysqld(Mrr_simple_index_reader::get_next(void**)+0x20) [0x682b20]
      /apps/svr/mariadb5/bin/mysqld(Mrr_ordered_rndpos_reader::refill_from_index_reader()+0x74) [0x685074]
      /apps/svr/mariadb5/bin/mysqld(Mrr_ordered_rndpos_reader::refill_buffer(bool)+0x54) [0x685194]
      /apps/svr/mariadb5/bin/mysqld(DsMrr_impl::dsmrr_next(void**)+0x45) [0x682d75]
      /apps/svr/mariadb5/bin/mysqld(QUICK_RANGE_SELECT::get_next()+0x52) [0x7e23e2]
      /apps/svr/mariadb5/bin/mysqld() [0x801b9d]
      /apps/svr/mariadb5/bin/mysqld(sub_select(JOIN*, st_join_table*, bool)+0x13c) [0x5cd36c]
      /apps/svr/mariadb5/bin/mysqld() [0x5cda4d]
      /apps/svr/mariadb5/bin/mysqld(JOIN::exec()+0xaf3) [0x5e0193]
      /apps/svr/mariadb5/bin/mysqld(mysql_select(THD*, Item***, TABLE_LIST*, unsigned int, List<Item>&, Item*, unsigned int, st_order*, st_order*, Item*, st_order*, unsigned long long, select_result*, st_select_lex_unit*, st_select_lex*)+0x1c8) [0x5e26d8]
      /apps/svr/mariadb5/bin/mysqld(handle_select(THD*, LEX*, select_result*, unsigned long)+0x2b4) [0x5e3324]
      /apps/svr/mariadb5/bin/mysqld() [0x58d8a8]
      /apps/svr/mariadb5/bin/mysqld(mysql_execute_command(THD*)+0x1e99) [0x591929]
      /apps/svr/mariadb5/bin/mysqld(mysql_parse(THD*, char*, unsigned int, Parser_state*)+0x1b0) [0x596d80]
      /apps/svr/mariadb5/bin/mysqld(dispatch_command(enum_server_command, THD*, char*, unsigned int)+0x15da) [0x59836a]
      /apps/svr/mariadb5/bin/mysqld(do_command(THD*)+0xdb) [0x59870b]
      /apps/svr/mariadb5/bin/mysqld(do_handle_one_connection(THD*)+0x144) [0x6529c4]
      /apps/svr/mariadb5/bin/mysqld(handle_one_connection+0x4c) [0x652afc]
      /apps/svr/mariadb5/bin/mysqld() [0xa79458]
      /lib64/libpthread.so.0() [0x348bc07851]
      /lib64/libc.so.6(clone+0x6d) [0x348b8e767d]
       
      Trying to get some variables.
      Some pointers may be invalid and cause the dump to abort.
      Query (0x2b22fc002c38): SELECT T.TMS_ORDER_ID, T.CUST_CODE   FROM TMS_ORDER T  use index (IND_ORDER_N1)  WHERE     T.ORDER_SUB_TYPE = 11        AND T.BUYER_CITY IS NOT NULL        AND T.BUYER_AREA_ID IS NOT NULL        AND T.BUYER_STATE IS NOT NULL        AND T.CREATED_OFFICE = 'VIP_NH'        AND (T.CARRIAGE IS NULL OR T.CARRIAGE = 0)        AND T.BUYER_ADDRESS = '         .         .                  92                     1201'        AND T.BUYER_AREA_ID = '104104119002'        AND (   (T.BUY_TOWN IS NULL )             OR (T.BUY_TOWN = null))        AND (   (    T.TRANSPORT_DAY IS NULL                 )             OR (T.TRANSPORT_DAY = '            (         /                  )'))        -- AND T.BUYER is not null        AND (   (T.MOBILE IS NULL)             OR (T.MOBILE = '18664055899'))        AND (   (    T.BUYER_TEL IS NULL                 )             OR (T.BUYER_TEL = ''))        AND (   (    T.TRANSPORT_TYPE IS NULL )             OR (T.TRANSPORT_TYPE = 0))        AND (T.IS_COD = 1)        AND T.ADD_TIME > TIMESTAMPADD(DAY, -14, CURRENT_TIMESTAMP)  LIMIT 1
      Connection ID (thread ID): 25474
      Status: KILL_QUERY
       
      Optimizer switch: index_merge=on,index_merge_union=on,index_merge_sort_union=on,index_merge_intersection=on,index_merge_sort_intersection=off,engine_condition_pushdown=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=on,mrr_cost_based=off,mrr_sort_keys=on,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=off,table_elimination=on,extended_keys=off
       
      The manual page at http://dev.mysql.com/doc/mysql/en/crashing.html contains
      information that should help you find out what is causing the crash.
      140421 10:07:24 mysqld_safe Number of processes running now: 0
      140421 10:07:24 mysqld_safe mysqld restarted
      140421 10:07:24 InnoDB: The InnoDB memory heap is disabled
      140421 10:07:24 InnoDB: Mutexes and rw_locks use GCC atomic builtins
      140421 10:07:24 InnoDB: Compressed tables use zlib 1.2.3
      140421 10:07:24 InnoDB: Using Linux native AIO
      140421 10:07:24 InnoDB: Initializing buffer pool, size = 80.0G
      140421 10:07:29 InnoDB: Completed initialization of buffer pool
      140421 10:07:29 InnoDB: highest supported file format is Barracuda.
      InnoDB: Log scan progressed past the checkpoint lsn 1557115877541
      140421 10:07:29  InnoDB: Database was not shut down normally!
      InnoDB: Starting crash recovery.
      InnoDB: Reading tablespace information from the .ibd files...
      InnoDB: Restoring possible half-written data pages from the doublewrite
      InnoDB: buffer...
      InnoDB: Doing recovery: scanned up to log sequence number 1557121120256
      InnoDB: Doing recovery: scanned up to log sequence number 1557126363136
      InnoDB: Doing recovery: scanned up to log sequence number 1557131606016
      InnoDB: Doing recovery: scanned up to log sequence number 1557133065602
      140421 10:07:31  InnoDB: Starting an apply batch of log records to the database...
      InnoDB: Progress in percents: 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 
      InnoDB: Apply batch completed
      140421 10:07:38  InnoDB: Waiting for the background threads to start
      140421 10:07:39 Percona XtraDB (http://www.percona.com) 5.5.31-MariaDB-30.2 started; log sequence number 1557133065602
      140421 10:07:39 [Note] Recovering after a crash using /apps/dbdat/mariadb5_data3306/log/mysql-bin
      140421 10:07:39 [Note] Starting crash recovery...
      140421 10:07:39 [Note] Crash recovery finished.
      140421 10:07:39 [Note] Server socket created on IP: '0.0.0.0'.
      140421 10:07:39 [Warning] 'user' entry 'root@GD6G2S113' ignored in --skip-name-resolve mode.
      140421 10:07:39 [Warning] 'user' entry '@GD6G2S113' ignored in --skip-name-resolve mode.
      140421 10:07:39 [Warning] 'proxies_priv' entry '@ root@GD6G2S113' ignored in --skip-name-resolve mode.
      140421 10:07:39 [Note] /apps/svr/mariadb5/bin/mysqld: ready for connections.
      Version: '5.5.31-MariaDB-log'  socket: '/tmp/mysql3306.sock'  port: 3306  MariaDB Server
      140421 10:07:39 [Note] Event Scheduler: scheduler thread started with id 1

      Attachments

        Activity

          People

            elenst Elena Stepanova
            wongyuenkin wongyuenkin
            Votes:
            0 Vote for this issue
            Watchers:
            3 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.