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

Hard crash in metadata_lock_info

Details

    • Bug
    • Status: Closed (View Workflow)
    • Major
    • Resolution: Fixed
    • 10.1.12, 10.0(EOL), 10.1(EOL)
    • 10.0.26, 10.1.15
    • Locking
    • None
    • 10.0.26

    Description

      Our server crashed today with the following stack trace:

      Server version: 10.1.12-MariaDB-1~trusty
      		 
      key_buffer_size=16777216
      		 
      read_buffer_size=131072
      		 
      max_used_connections=227
      		 
      max_threads=502
      		 
      thread_count=59
      		 
      It is possible that mysqld could use up to 
      key_buffer_size + (read_buffer_size + sort_buffer_size)*max_threads = 1118998 K  bytes of memory
      		 
      Hope that's ok; if not, decrease some variables in the equation.
      		 
       
      		 
      Thread pointer: 0x0x7fd005084008
      		 
      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 = 0x7fcfe1e6bdf0 thread_stack 0x80000
      		 
      *** buffer overflow detected ***: /usr/sbin/mysqld terminated
      		 
      ======= Backtrace: =========
      		 
      /lib/x86_64-linux-gnu/libc.so.6(+0x7338f)[0x7fde8d17c38f]
      		 
      /lib/x86_64-linux-gnu/libc.so.6(__fortify_fail+0x5c)[0x7fde8d213c9c]
      		 
      /lib/x86_64-linux-gnu/libc.so.6(+0x109b60)[0x7fde8d212b60]
      		 
      /lib/x86_64-linux-gnu/libc.so.6(+0x10abe7)[0x7fde8d213be7]
      		 
      /usr/sbin/mysqld(my_addr_resolve+0x48)[0x7fde8fa78af8]
      		 
      /usr/sbin/mysqld(my_print_stacktrace+0x1c2)[0x7fde8fa651f2]
      		 
      /usr/sbin/mysqld(handle_fatal_signal+0x38d)[0x7fde8f5921bd]
      		 
      /lib/x86_64-linux-gnu/libpthread.so.0(+0x10340)[0x7fde8dae8340]
      		 
      /usr/sbin/mysqld(_ZN11MDL_context11find_ticketEP11MDL_requestP17enum_mdl_duration+0x68)[0x7fde8f4e9948]
      		 
      /usr/lib/mysql/plugin/metadata_lock_info.so(_Z31i_s_metadata_lock_info_fill_rowP10MDL_ticketPv+0x74)[0x7fde88dfdfa4]
      		 
      /usr/sbin/mysqld(+0x5057cd)[0x7fde8f4e77cd]
      		 
      /usr/sbin/mysqld(lf_hash_iterate+0x193)[0x7fde8fa6ec03]
      		 
      /usr/sbin/mysqld(_Z11mdl_iteratePFiP10MDL_ticketPvES1_+0x8f)[0x7fde8f4e7a6f]
      		 
      /usr/lib/mysql/plugin/metadata_lock_info.so(_Z33i_s_metadata_lock_info_fill_tableP3THDP10TABLE_LISTP4Item+0x27)[0x7fde88dfe197]
      		 
      /usr/sbin/mysqld(_Z24get_schema_tables_resultP4JOIN23enum_schema_table_state+0x28e)[0x7fde8f48222e]
      		 
      /usr/sbin/mysqld(_ZN4JOIN10exec_innerEv+0x6bd)[0x7fde8f46885d]
      		 
      /usr/sbin/mysqld(_ZN4JOIN4execEv+0x54)[0x7fde8f46ace4]
      		 
      /usr/sbin/mysqld(_Z12mysql_selectP3THDPPP4ItemP10TABLE_LISTjR4ListIS1_ES2_jP8st_orderSB_S2_SB_yP13select_resultP18st_select_lex_unitP13st_select_lex+0x112)[0x7fde8f467392]
      		 
      /usr/sbin/mysqld(_Z18mysql_derived_fillP3THDP3LEXP10TABLE_LIST+0x11b)[0x7fde8f3ef86b]
      		 
      /usr/sbin/mysqld(_Z27mysql_handle_single_derivedP3LEXP10TABLE_LISTj+0xe4)[0x7fde8f3f0b74]
      		 
      /usr/sbin/mysqld(_ZN13st_join_table12preread_initEv+0xcf)[0x7fde8f44b0df]
      		 
      /usr/sbin/mysqld(_Z10sub_selectP4JOINP13st_join_tableb+0x2f8)[0x7fde8f44b568]
      		 
      /usr/sbin/mysqld(+0x476fed)[0x7fde8f458fed]
      		 
      /usr/sbin/mysqld(_ZN4JOIN10exec_innerEv+0xb4c)[0x7fde8f468cec]
      		 
      /usr/sbin/mysqld(_ZN4JOIN4execEv+0x54)[0x7fde8f46ace4]
      		 
      /usr/sbin/mysqld(_Z12mysql_selectP3THDPPP4ItemP10TABLE_LISTjR4ListIS1_ES2_jP8st_orderSB_S2_SB_yP13select_resultP18st_select_lex_unitP13st_select_lex+0x112)[0x7fde8f467392]
      		 
      /usr/sbin/mysqld(_Z13handle_selectP3THDP3LEXP13select_resultm+0x245)[0x7fde8f467e75]
      		 
      /usr/sbin/mysqld(+0x428351)[0x7fde8f40a351]
      		 
      /usr/sbin/mysqld(_Z21mysql_execute_commandP3THD+0x61e4)[0x7fde8f416854]
      		 
      /usr/sbin/mysqld(_Z11mysql_parseP3THDPcjP12Parser_state+0x26d)[0x7fde8f419fed]
      		 
      /usr/sbin/mysqld(_Z16dispatch_command19enum_server_commandP3THDPcj+0x2460)[0x7fde8f41d330]
      		 
      /usr/sbin/mysqld(_Z10do_commandP3THD+0x169)[0x7fde8f41dae9]
      		 
      /usr/sbin/mysqld(_Z24do_handle_one_connectionP3THD+0x18a)[0x7fde8f4e10fa]
      		 
      /usr/sbin/mysqld(handle_one_connection+0x40)[0x7fde8f4e12d0]
      		 
      /lib/x86_64-linux-gnu/libpthread.so.0(+0x8182)[0x7fde8dae0182]
      		 
      /lib/x86_64-linux-gnu/libc.so.6(clone+0x6d)[0x7fde8d20347d]

      My.cnf files can be found in my other issues about other crashes.

      We are monitoring the server status with this query:

      SELECT
      		 
        `information_schema`.`metadata_lock_info`.`THREAD_ID`     AS `THREAD_ID`,
      		 
        CONCAT(`information_schema`.`processlist`.`USER`,'@',`information_schema`.`processlist`.`HOST`) AS `USER`,
      		 
        REPLACE(`information_schema`.`processlist`.`INFO`,'\n',' ') AS `QUERY`,
      		 
        `information_schema`.`metadata_lock_info`.`LOCK_MODE`     AS `LOCK_MODE`,
      		 
        `information_schema`.`metadata_lock_info`.`LOCK_TYPE`     AS `LOCK_TYPE`,
      		 
        GROUP_CONCAT(CONCAT(`information_schema`.`metadata_lock_info`.`TABLE_SCHEMA`,'.',`information_schema`.`metadata_lock_info`.`TABLE_NAME`) SEPARATOR ',') AS `LOCK_TABLES`,
      		 
        `information_schema`.`metadata_lock_info`.`LOCK_DURATION` AS `LOCK_DURATION`,
      		 
        ROUND((`information_schema`.`processlist`.`TIME_MS` / 1000),2) AS `DURATION`
      		 
      FROM (`information_schema`.`metadata_lock_info`
      		 
         JOIN `information_schema`.`processlist`
      		 
           ON ((`information_schema`.`metadata_lock_info`.`THREAD_ID` = `information_schema`.`processlist`.`ID`)))
      		 
      GROUP BY `information_schema`.`metadata_lock_info`.`THREAD_ID`,`information_schema`.`metadata_lock_info`.`LOCK_MODE`,`information_schema`.`metadata_lock_info`.`LOCK_TYPE`$$

      But the server didn't crash when I was executing this query, so it might be something else. Come to think of it, there might have been a very small network hiccup. (Which is why it crashed on an addr_resolve)

      Attachments

        Issue Links

          causes

          Bug - A problem which impairs or prevents the functions of the product. MDEV-14307 LOCK_DURATION always NULL in METADATA_LOCK_INFO

          • Major - Major loss of function.
          • Closed
          relates to

          Bug - A problem which impairs or prevents the functions of the product. MDEV-9486 Crash in metadata lock plugin

          • Major - Major loss of function.
          • Closed

          Bug - A problem which impairs or prevents the functions of the product. MDEV-12523 MariaDB server crash with METADATA_LOCK_INFO Plugin

          • Major - Major loss of function.
          • Closed

          Activity

            Ascending order - Click to sort in descending order
            CrewOne Sander Pilon created issue -
            CrewOne Sander Pilon made changes -
            Field Original Value New Value
            Description Our server crashed today with the following stack trace:

            {code}
            Server version: 10.1.12-MariaDB-1~trusty
            key_buffer_size=16777216
            read_buffer_size=131072
            max_used_connections=227
            max_threads=502
            thread_count=59
            It is possible that mysqld could use up to
            key_buffer_size + (read_buffer_size + sort_buffer_size)*max_threads = 1118998 K bytes of memory
            Hope that's ok; if not, decrease some variables in the equation.

            Thread pointer: 0x0x7fd005084008
            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 = 0x7fcfe1e6bdf0 thread_stack 0x80000
            *** buffer overflow detected ***: /usr/sbin/mysqld terminated
            ======= Backtrace: =========
            /lib/x86_64-linux-gnu/libc.so.6(+0x7338f)[0x7fde8d17c38f]
            /lib/x86_64-linux-gnu/libc.so.6(__fortify_fail+0x5c)[0x7fde8d213c9c]
            /lib/x86_64-linux-gnu/libc.so.6(+0x109b60)[0x7fde8d212b60]
            /lib/x86_64-linux-gnu/libc.so.6(+0x10abe7)[0x7fde8d213be7]
            /usr/sbin/mysqld(my_addr_resolve+0x48)[0x7fde8fa78af8]
            /usr/sbin/mysqld(my_print_stacktrace+0x1c2)[0x7fde8fa651f2]
            /usr/sbin/mysqld(handle_fatal_signal+0x38d)[0x7fde8f5921bd]
            /lib/x86_64-linux-gnu/libpthread.so.0(+0x10340)[0x7fde8dae8340]
            /usr/sbin/mysqld(_ZN11MDL_context11find_ticketEP11MDL_requestP17enum_mdl_duration+0x68)[0x7fde8f4e9948]
            /usr/lib/mysql/plugin/metadata_lock_info.so(_Z31i_s_metadata_lock_info_fill_rowP10MDL_ticketPv+0x74)[0x7fde88dfdfa4]
            /usr/sbin/mysqld(+0x5057cd)[0x7fde8f4e77cd]
            /usr/sbin/mysqld(lf_hash_iterate+0x193)[0x7fde8fa6ec03]
            /usr/sbin/mysqld(_Z11mdl_iteratePFiP10MDL_ticketPvES1_+0x8f)[0x7fde8f4e7a6f]
            /usr/lib/mysql/plugin/metadata_lock_info.so(_Z33i_s_metadata_lock_info_fill_tableP3THDP10TABLE_LISTP4Item+0x27)[0x7fde88dfe197]
            /usr/sbin/mysqld(_Z24get_schema_tables_resultP4JOIN23enum_schema_table_state+0x28e)[0x7fde8f48222e]
            /usr/sbin/mysqld(_ZN4JOIN10exec_innerEv+0x6bd)[0x7fde8f46885d]
            /usr/sbin/mysqld(_ZN4JOIN4execEv+0x54)[0x7fde8f46ace4]
            /usr/sbin/mysqld(_Z12mysql_selectP3THDPPP4ItemP10TABLE_LISTjR4ListIS1_ES2_jP8st_orderSB_S2_SB_yP13select_resultP18st_select_lex_unitP13st_select_lex+0x112)[0x7fde8f467392]
            /usr/sbin/mysqld(_Z18mysql_derived_fillP3THDP3LEXP10TABLE_LIST+0x11b)[0x7fde8f3ef86b]
            /usr/sbin/mysqld(_Z27mysql_handle_single_derivedP3LEXP10TABLE_LISTj+0xe4)[0x7fde8f3f0b74]
            /usr/sbin/mysqld(_ZN13st_join_table12preread_initEv+0xcf)[0x7fde8f44b0df]
            /usr/sbin/mysqld(_Z10sub_selectP4JOINP13st_join_tableb+0x2f8)[0x7fde8f44b568]
            /usr/sbin/mysqld(+0x476fed)[0x7fde8f458fed]
            /usr/sbin/mysqld(_ZN4JOIN10exec_innerEv+0xb4c)[0x7fde8f468cec]
            /usr/sbin/mysqld(_ZN4JOIN4execEv+0x54)[0x7fde8f46ace4]
            /usr/sbin/mysqld(_Z12mysql_selectP3THDPPP4ItemP10TABLE_LISTjR4ListIS1_ES2_jP8st_orderSB_S2_SB_yP13select_resultP18st_select_lex_unitP13st_select_lex+0x112)[0x7fde8f467392]
            /usr/sbin/mysqld(_Z13handle_selectP3THDP3LEXP13select_resultm+0x245)[0x7fde8f467e75]
            /usr/sbin/mysqld(+0x428351)[0x7fde8f40a351]
            /usr/sbin/mysqld(_Z21mysql_execute_commandP3THD+0x61e4)[0x7fde8f416854]
            /usr/sbin/mysqld(_Z11mysql_parseP3THDPcjP12Parser_state+0x26d)[0x7fde8f419fed]
            /usr/sbin/mysqld(_Z16dispatch_command19enum_server_commandP3THDPcj+0x2460)[0x7fde8f41d330]
            /usr/sbin/mysqld(_Z10do_commandP3THD+0x169)[0x7fde8f41dae9]
            /usr/sbin/mysqld(_Z24do_handle_one_connectionP3THD+0x18a)[0x7fde8f4e10fa]
            /usr/sbin/mysqld(handle_one_connection+0x40)[0x7fde8f4e12d0]
            /lib/x86_64-linux-gnu/libpthread.so.0(+0x8182)[0x7fde8dae0182]
            /lib/x86_64-linux-gnu/libc.so.6(clone+0x6d)[0x7fde8d20347d]
            {code}

            My.cnf files can be found in my other issues about other crashes.

            We are monitoring the server status with this query:

            {code}
            SELECT
              `information_schema`.`metadata_lock_info`.`THREAD_ID` AS `THREAD_ID`,
              CONCAT(`information_schema`.`processlist`.`USER`,'@',`information_schema`.`processlist`.`HOST`) AS `USER`,
              REPLACE(`information_schema`.`processlist`.`INFO`,'\n',' ') AS `QUERY`,
              `information_schema`.`metadata_lock_info`.`LOCK_MODE` AS `LOCK_MODE`,
              `information_schema`.`metadata_lock_info`.`LOCK_TYPE` AS `LOCK_TYPE`,
              GROUP_CONCAT(CONCAT(`information_schema`.`metadata_lock_info`.`TABLE_SCHEMA`,'.',`information_schema`.`metadata_lock_info`.`TABLE_NAME`) SEPARATOR ',') AS `LOCK_TABLES`,
              `information_schema`.`metadata_lock_info`.`LOCK_DURATION` AS `LOCK_DURATION`,
              ROUND((`information_schema`.`processlist`.`TIME_MS` / 1000),2) AS `DURATION`
            FROM (`information_schema`.`metadata_lock_info`
               JOIN `information_schema`.`processlist`
                 ON ((`information_schema`.`metadata_lock_info`.`THREAD_ID` = `information_schema`.`processlist`.`ID`)))
            GROUP BY `information_schema`.`metadata_lock_info`.`THREAD_ID`,`information_schema`.`metadata_lock_info`.`LOCK_MODE`,`information_schema`.`metadata_lock_info`.`LOCK_TYPE`$$
            {code}

            But the server didn't crash when I was executing this query, so it might be something else.             		Our server crashed today with the following stack trace:

            {code}
            Server version: 10.1.12-MariaDB-1~trusty
            key_buffer_size=16777216
            read_buffer_size=131072
            max_used_connections=227
            max_threads=502
            thread_count=59
            It is possible that mysqld could use up to
            key_buffer_size + (read_buffer_size + sort_buffer_size)*max_threads = 1118998 K bytes of memory
            Hope that's ok; if not, decrease some variables in the equation.

            Thread pointer: 0x0x7fd005084008
            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 = 0x7fcfe1e6bdf0 thread_stack 0x80000
            *** buffer overflow detected ***: /usr/sbin/mysqld terminated
            ======= Backtrace: =========
            /lib/x86_64-linux-gnu/libc.so.6(+0x7338f)[0x7fde8d17c38f]
            /lib/x86_64-linux-gnu/libc.so.6(__fortify_fail+0x5c)[0x7fde8d213c9c]
            /lib/x86_64-linux-gnu/libc.so.6(+0x109b60)[0x7fde8d212b60]
            /lib/x86_64-linux-gnu/libc.so.6(+0x10abe7)[0x7fde8d213be7]
            /usr/sbin/mysqld(my_addr_resolve+0x48)[0x7fde8fa78af8]
            /usr/sbin/mysqld(my_print_stacktrace+0x1c2)[0x7fde8fa651f2]
            /usr/sbin/mysqld(handle_fatal_signal+0x38d)[0x7fde8f5921bd]
            /lib/x86_64-linux-gnu/libpthread.so.0(+0x10340)[0x7fde8dae8340]
            /usr/sbin/mysqld(_ZN11MDL_context11find_ticketEP11MDL_requestP17enum_mdl_duration+0x68)[0x7fde8f4e9948]
            /usr/lib/mysql/plugin/metadata_lock_info.so(_Z31i_s_metadata_lock_info_fill_rowP10MDL_ticketPv+0x74)[0x7fde88dfdfa4]
            /usr/sbin/mysqld(+0x5057cd)[0x7fde8f4e77cd]
            /usr/sbin/mysqld(lf_hash_iterate+0x193)[0x7fde8fa6ec03]
            /usr/sbin/mysqld(_Z11mdl_iteratePFiP10MDL_ticketPvES1_+0x8f)[0x7fde8f4e7a6f]
            /usr/lib/mysql/plugin/metadata_lock_info.so(_Z33i_s_metadata_lock_info_fill_tableP3THDP10TABLE_LISTP4Item+0x27)[0x7fde88dfe197]
            /usr/sbin/mysqld(_Z24get_schema_tables_resultP4JOIN23enum_schema_table_state+0x28e)[0x7fde8f48222e]
            /usr/sbin/mysqld(_ZN4JOIN10exec_innerEv+0x6bd)[0x7fde8f46885d]
            /usr/sbin/mysqld(_ZN4JOIN4execEv+0x54)[0x7fde8f46ace4]
            /usr/sbin/mysqld(_Z12mysql_selectP3THDPPP4ItemP10TABLE_LISTjR4ListIS1_ES2_jP8st_orderSB_S2_SB_yP13select_resultP18st_select_lex_unitP13st_select_lex+0x112)[0x7fde8f467392]
            /usr/sbin/mysqld(_Z18mysql_derived_fillP3THDP3LEXP10TABLE_LIST+0x11b)[0x7fde8f3ef86b]
            /usr/sbin/mysqld(_Z27mysql_handle_single_derivedP3LEXP10TABLE_LISTj+0xe4)[0x7fde8f3f0b74]
            /usr/sbin/mysqld(_ZN13st_join_table12preread_initEv+0xcf)[0x7fde8f44b0df]
            /usr/sbin/mysqld(_Z10sub_selectP4JOINP13st_join_tableb+0x2f8)[0x7fde8f44b568]
            /usr/sbin/mysqld(+0x476fed)[0x7fde8f458fed]
            /usr/sbin/mysqld(_ZN4JOIN10exec_innerEv+0xb4c)[0x7fde8f468cec]
            /usr/sbin/mysqld(_ZN4JOIN4execEv+0x54)[0x7fde8f46ace4]
            /usr/sbin/mysqld(_Z12mysql_selectP3THDPPP4ItemP10TABLE_LISTjR4ListIS1_ES2_jP8st_orderSB_S2_SB_yP13select_resultP18st_select_lex_unitP13st_select_lex+0x112)[0x7fde8f467392]
            /usr/sbin/mysqld(_Z13handle_selectP3THDP3LEXP13select_resultm+0x245)[0x7fde8f467e75]
            /usr/sbin/mysqld(+0x428351)[0x7fde8f40a351]
            /usr/sbin/mysqld(_Z21mysql_execute_commandP3THD+0x61e4)[0x7fde8f416854]
            /usr/sbin/mysqld(_Z11mysql_parseP3THDPcjP12Parser_state+0x26d)[0x7fde8f419fed]
            /usr/sbin/mysqld(_Z16dispatch_command19enum_server_commandP3THDPcj+0x2460)[0x7fde8f41d330]
            /usr/sbin/mysqld(_Z10do_commandP3THD+0x169)[0x7fde8f41dae9]
            /usr/sbin/mysqld(_Z24do_handle_one_connectionP3THD+0x18a)[0x7fde8f4e10fa]
            /usr/sbin/mysqld(handle_one_connection+0x40)[0x7fde8f4e12d0]
            /lib/x86_64-linux-gnu/libpthread.so.0(+0x8182)[0x7fde8dae0182]
            /lib/x86_64-linux-gnu/libc.so.6(clone+0x6d)[0x7fde8d20347d]
            {code}

            My.cnf files can be found in my other issues about other crashes.

            We are monitoring the server status with this query:

            {code}
            SELECT
              `information_schema`.`metadata_lock_info`.`THREAD_ID` AS `THREAD_ID`,
              CONCAT(`information_schema`.`processlist`.`USER`,'@',`information_schema`.`processlist`.`HOST`) AS `USER`,
              REPLACE(`information_schema`.`processlist`.`INFO`,'\n',' ') AS `QUERY`,
              `information_schema`.`metadata_lock_info`.`LOCK_MODE` AS `LOCK_MODE`,
              `information_schema`.`metadata_lock_info`.`LOCK_TYPE` AS `LOCK_TYPE`,
              GROUP_CONCAT(CONCAT(`information_schema`.`metadata_lock_info`.`TABLE_SCHEMA`,'.',`information_schema`.`metadata_lock_info`.`TABLE_NAME`) SEPARATOR ',') AS `LOCK_TABLES`,
              `information_schema`.`metadata_lock_info`.`LOCK_DURATION` AS `LOCK_DURATION`,
              ROUND((`information_schema`.`processlist`.`TIME_MS` / 1000),2) AS `DURATION`
            FROM (`information_schema`.`metadata_lock_info`
               JOIN `information_schema`.`processlist`
                 ON ((`information_schema`.`metadata_lock_info`.`THREAD_ID` = `information_schema`.`processlist`.`ID`)))
            GROUP BY `information_schema`.`metadata_lock_info`.`THREAD_ID`,`information_schema`.`metadata_lock_info`.`LOCK_MODE`,`information_schema`.`metadata_lock_info`.`LOCK_TYPE`$$
            {code}

            But the server didn't crash when I was executing this query, so it might be something else. Come to think of it, there might have been a very small network hiccup. (Which is why it crashed on an addr_resolve)
            elenst Elena Stepanova made changes -
            Affects Version/s 10.1.12 [ 21502 ]
            elenst Elena Stepanova made changes -
            Assignee Elena Stepanova [ elenst ]
            elenst Elena Stepanova made changes -
            Status Open [ 1 ] Confirmed [ 10101 ]
            elenst Elena Stepanova made changes -
            Component/s Locking [ 10900 ]
            Fix Version/s 10.0 [ 16000 ]
            Fix Version/s 10.1 [ 16100 ]
            Affects Version/s 10.0 [ 16000 ]
            Affects Version/s 10.1 [ 16100 ]
            Assignee Elena Stepanova [ elenst ] Sergey Vojtovich [ svoj ]
            serg Sergei Golubchik made changes -
            Sprint 10.0.26 [ 73 ]
            svoj Sergey Vojtovich made changes -
            Assignee Sergey Vojtovich [ svoj ] Elena Stepanova [ elenst ]
            elenst Elena Stepanova made changes -
            Assignee Elena Stepanova [ elenst ] Sergei Golubchik [ serg ]
            Status Confirmed [ 10101 ] In Review [ 10002 ]
            serg Sergei Golubchik made changes -
            Assignee Sergei Golubchik [ serg ] Sergey Vojtovich [ svoj ]
            Status In Review [ 10002 ] Stalled [ 10000 ]
            elenst Elena Stepanova made changes -
            Assignee Sergey Vojtovich [ svoj ] Elena Stepanova [ elenst ]
            svoj Sergey Vojtovich made changes -
            Assignee Elena Stepanova [ elenst ] Sergei Golubchik [ serg ]
            svoj Sergey Vojtovich made changes -
            Assignee Sergei Golubchik [ serg ] Sergey Vojtovich [ svoj ]
            elenst Elena Stepanova made changes -
            Comment [ I've got the crash below with 3e75558d4d0350ed71c02b09dd3b86b05db14b9d -- it looks related, does it not?

            {noformat}
            Thread pointer: 0x0x7f95a5ea0070
            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 = 0x7f96d5ce8e10 thread_stack 0x80000
            /home/elenst/git/10.0/sql/mysqld(my_print_stacktrace+0x38)[0xe74ab6]
            sql/signal_handler.cc:155(handle_fatal_signal)[0x85fcdd]
            /lib/x86_64-linux-gnu/libpthread.so.0(+0xfcb0)[0x7f96d718ccb0]
            ctype-utf8.c:0(my_valid_mbcharlen_utf8)[0xeac15e]
            ctype-utf8.c:0(my_well_formed_len_utf8)[0xeac1cd]
            sql/sql_string.cc:980(well_formed_copy_nchars(charset_info_st const*, char*, unsigned int, charset_info_st const*, char const*, unsigned int, unsigned int, char const**, char const**, char const**))[0x706e35]
            sql/field.cc:6866(Field_varstring::store(char const*, unsigned int, charset_info_st const*))[0x8469f6]
            /home/elenst/git/10.0/lib/plugin/metadata_lock_info.so(_Z31i_s_metadata_lock_info_fill_rowP10MDL_ticketPv+0x28b)[0x7f959a1f37a3]
            sql/mdl.cc:713(mdl_iterate_lock(MDL_lock*, int (*)(MDL_ticket*, void*), void*))[0x7900ba]
            sql/mdl.cc:756(mdl_iterate(int (*)(MDL_ticket*, void*), void*))[0x790309]
            /home/elenst/git/10.0/lib/plugin/metadata_lock_info.so(_Z33i_s_metadata_lock_info_fill_tableP3THDP10TABLE_LISTP4Item+0x71)[0x7f959a1f3a23]
            sql/sql_show.cc:8168(get_schema_tables_result(JOIN*, enum_schema_table_state))[0x6f9b19]
            sql/sql_select.cc:2537(JOIN::exec_inner())[0x69c30a]
            sql/sql_select.cc:2375(JOIN::exec())[0x69b8fe]
            sql/sql_select.cc:3310(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*))[0x69ef3b]
            sql/sql_select.cc:373(handle_select(THD*, LEX*, select_result*, unsigned long))[0x694f03]
            sql/sql_parse.cc:5293(execute_sqlcom_select(THD*, TABLE_LIST*))[0x667b05]
            sql/sql_parse.cc:2562(mysql_execute_command(THD*))[0x65fcf9]
            sql/sql_parse.cc:6574(mysql_parse(THD*, char*, unsigned int, Parser_state*))[0x66a90d]
            sql/sql_parse.cc:1310(dispatch_command(enum_server_command, THD*, char*, unsigned int))[0x65ce95]
            sql/sql_parse.cc:998(do_command(THD*))[0x65c114]
            sql/sql_connect.cc:1378(do_handle_one_connection(THD*))[0x786f7b]
            sql/sql_connect.cc:1294(handle_one_connection)[0x786ced]
            /lib/x86_64-linux-gnu/libpthread.so.0(+0x7e9a)[0x7f96d7184e9a]
            /lib/x86_64-linux-gnu/libc.so.6(clone+0x6d)[0x7f96d6074cbd]

            Trying to get some variables.
            Some pointers may be invalid and cause the dump to abort.
            Query (0x7f95a3023088): SELECT `information_schema`.`metadata_lock_info`.`THREAD_ID` AS `THREAD_ID`, CONCAT(`information_schema`.`processlist`.`USER`,'@',`information_schema`.`processlist`.`HOST`) AS `USER`, REPLACE(`information_schema`.`processlist`.`INFO`,'\n',' ') AS `QUERY`, `information_schema`.`metadata_lock_info`.`LOCK_MODE` AS `LOCK_MODE`, `information_schema`.`metadata_lock_info`.`LOCK_TYPE` AS `LOCK_TYPE`, GROUP_CONCAT(CONCAT(`information_schema`.`metadata_lock_info`.`TABLE_SCHEMA`,'.',`information_schema`.`metadata_lock_info`.`TABLE_NAME`) SEPARATOR ',') AS `LOCK_TABLES`, `information_schema`.`metadata_lock_info`.`LOCK_DURATION` AS `LOCK_DURATION`, ROUND((`information_schema`.`processlist`.`TIME_MS` / 1000),2) AS `DURATION` FROM (`information_schema`.`metadata_lock_info` JOIN `information_schema`.`processlist` ON ((`information_schema`.`metadata_lock_info`.`THREAD_ID` = `information_schema`.`processlist`.`ID`))) GROUP BY `information_schema`.`metadata_lock_info`.`THREAD_ID`,`information_schema`.`metadata_lock_info`.`LOCK_MODE`,`information_schema`.`metadata_lock_info`.`LOCK_TYPE`
            Connection ID (thread ID): 9
            {noformat} ]
            svoj Sergey Vojtovich made changes -
            Assignee Sergey Vojtovich [ svoj ] Sergei Golubchik [ serg ]
            Status Stalled [ 10000 ] In Review [ 10002 ]
            serg Sergei Golubchik made changes -
            Assignee Sergei Golubchik [ serg ] Sergey Vojtovich [ svoj ]
            Status In Review [ 10002 ] Stalled [ 10000 ]
            svoj Sergey Vojtovich made changes -
            Fix Version/s 10.0.26 [ 22016 ]
            Fix Version/s 10.1.15 [ 22018 ]
            Fix Version/s 10.2.1 [ 22012 ]
            Fix Version/s 10.0 [ 16000 ]
            Fix Version/s 10.1 [ 16100 ]
            Resolution Fixed [ 1 ]
            Status Stalled [ 10000 ] Closed [ 6 ]
            serg Sergei Golubchik made changes -
            Fix Version/s 10.2.1 [ 22012 ]
            elenst Elena Stepanova made changes -
            elenst Elena Stepanova made changes -
            hholzgra Hartmut Holzgraefe made changes -
            serg Sergei Golubchik made changes -
            Workflow MariaDB v3 [ 74550 ] MariaDB v4 [ 150223 ]

            People

              svoj Sergey Vojtovich
              CrewOne Sander Pilon
              Votes:
              1 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.