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

LP:1000863 - MariaDB crashes on insert containing doubly nested subselect

    Details

    • Type: Bug
    • Status: Closed
    • Resolution: Duplicate
    • Affects Version/s: None
    • Fix Version/s: None
    • Component/s: None
    • Labels:

      Description

      When attempting to perform an INSERT query that contains nested sub-SELECTs MariaDB 5.5.23 crashes with the following error:

      This happened on Ubuntu 10.04.3 LTS using the stable version of MariaDB in the lucid release repo.

      The system is running kernel 2.6.32-33-server on amd64 (4 logical CPUs). 16gb of RAM. We are using ext4 on an md raid10 volume to store the data directory. The system does not run any other significant processes, just a pretty vanilla installation of Ubuntu running MariaDB.

      The server is not participating in replication. No other activity on the server at the time of crash except running the query below. (This server is non-production).

      Unfortunately I cannot provide a core dump due to security requirements (we are dealing with customer data). Names/values have been redacted as appropriate below for the same reason.

      Contents of error log with server compiled in debug mode at time of crash:

      --SNIP--

      InnoDB: DEBUG: update_statistics for redacted/#sql-6f38_4.
      InnoDB: DEBUG: update_statistics for redacted/#sql-6f38_4.
      InnoDB: DEBUG: update_statistics for redacted/platform_app.
      120517 11:29:50 [ERROR] mysqld got signal 11 ;
      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.23-MariaDB-debug-log
      key_buffer_size=16777216
      read_buffer_size=131072
      max_used_connections=1
      max_threads=153
      thread_count=1
      It is possible that mysqld could use up to
      key_buffer_size + (read_buffer_size + sort_buffer_size)*max_threads = 351502 K bytes of memory
      Hope that's ok; if not, decrease some variables in the equation.

      Thread pointer: 0x0x7f56780257e0
      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 = 0x7f59c35e0e40 thread_stack 0x30000
      mysys/stacktrace.c:246(my_print_stacktrace)[0xc7cb8a]
      sql/signal_handler.cc:172(handle_fatal_signal)[0x7cfecd]
      :0()[0x7f59c31f38f0]
      sql/item.cc:9588(Item_ref::update_used_tables())[0x7fa5b0]
      sql/item_func.cc:447(Item_func::update_used_tables())[0x8307be]
      sql/sql_lex.cc:3786(st_select_lex::update_used_tables())[0x6084e1]
      sql/sql_select.cc:975(JOIN::optimize())[0x642c2a]
      sql/item_subselect.cc:2934(subselect_single_select_engine::exec())[0x8738c7]
      sql/item_subselect.cc:597(Item_subselect::exec())[0x86c733]
      sql/item_subselect.cc:1113(Item_singlerow_subselect::val_int())[0x86df32]
      sql/item.cc:5888(Item::save_in_field(Field*, bool))[0x7eef5f]
      sql/sql_base.cc:8823(fill_record)[0x5bd796]
      sql/sql_base.cc:8880(fill_record_n_invoke_before_triggers(THD*, List<Item>&, List<Item>&, bool, Table_triggers_list*, trg_event_type))[0x5bd980]
      sql/sql_insert.cc:886(mysql_insert(THD*, TABLE_LIST*, List<Item>&, List<List<Item> >&, List<Item>&, List<Item>&, enum_duplicates, bool))[0x5f4866]
      sql/sql_parse.cc:2917(mysql_execute_command(THD*))[0x613630]
      sql/sql_parse.cc:5731(mysql_parse(THD*, char*, unsigned int, Parser_state*))[0x61b7b6]
      sql/sql_parse.cc:1057(dispatch_command(enum_server_command, THD*, char*, unsigned int))[0x60eea2]
      sql/sql_parse.cc:794(do_command(THD*))[0x60e13c]
      sql/sql_connect.cc:1253(do_handle_one_connection(THD*))[0x713ed6]
      sql/sql_connect.cc:1169(handle_one_connection)[0x713999]
      :0()[0x7f59c31ea9ca]
      :0()[0x7f59c1f3d70d]

      Trying to get some variables.
      Some pointers may be invalid and cause the dump to abort.
      Query (0x7f56802c7d38): is an invalid pointer
      Connection ID (thread ID): 4
      Status: NOT_KILLED

      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=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=off,table_elimination=on,extended_keys=off

      --SNIP--

      Query in question that caused the server to crash:

      --SNIP--

      INSERT INTO platform_app (platform_id, visible, name, `order`, type, url_action, url_about,
      access_level, `restrict`, `hidden`, parent_platform_app_id, module)
      VALUES (
      2,1,'redacted',1,0,'redacted','',0,'','',
      (
      SELECT platform_app_id FROM (
      SELECT * FROM platform_app
      ) AS temp WHERE temp.name = 'redacted'
      ),
      ''
      )

      --SNIP--

      SHOW CREATE TABLE for the table in question (platform_app):

      --SNIP--

      CREATE TABLE `platform_app` (
      `platform_app_id` int(11) NOT NULL AUTO_INCREMENT,
      `platform_id` int(11) NOT NULL,
      `visible` tinyint(1) NOT NULL,
      `name` varchar(32) COLLATE utf8_unicode_ci DEFAULT NULL,
      `order` int(11) NOT NULL,
      `type` int(11) NOT NULL,
      `url_action` varchar(192) COLLATE utf8_unicode_ci DEFAULT NULL,
      `url_about` varchar(192) COLLATE utf8_unicode_ci DEFAULT NULL,
      `access_level` int(11) NOT NULL,
      `restrict` varchar(64) COLLATE utf8_unicode_ci DEFAULT NULL,
      `hidden` varchar(64) COLLATE utf8_unicode_ci DEFAULT NULL,
      `parent_platform_app_id` int(11) NOT NULL DEFAULT '0',
      `module` varchar(32) COLLATE utf8_unicode_ci NOT NULL DEFAULT '',
      PRIMARY KEY (`platform_app_id`),
      KEY `platform_id` (`platform_id`)
      ) ENGINE=InnoDB AUTO_INCREMENT=115 DEFAULT CHARSET=utf8 COLLATE=utf8_unicode_ci

      --SNIP--

      Contents of my.cnf:

      --SNIP--

      [client]
      port = 3306
      socket = /var/run/mysqld/mysqld.sock

      [mysqld_safe]
      socket = /var/run/mysqld/mysqld.sock
      nice = 0
      syslog

      [mysqld]
      user = mysql
      socket = /var/run/mysqld/mysqld.sock
      port = 3306
      basedir = /usr
      datadir = /var/lib/mysql
      tmpdir = /tmp
      skip-external-locking
      bind-address = 10.0.0.98
      key_buffer = 16M
      max_allowed_packet = 16M
      thread_stack = 192K
      thread_cache_size = 8
      myisam-recover = BACKUP
      query_cache_limit = 1M
      query_cache_size = 16M
      general_log_file = /var/log/mysql/mysql.log
      log_error = /var/log/mysql/error.log
      log_bin = /var/log/mysql/mysql-bin.log
      expire_logs_days = 5
      max_binlog_size = 100M
      server-id=23
      replicate-same-server-id=0
      log-slave-updates
      innodb_buffer_pool_size = 12G
      innodb_log_buffer_size = 8M
      innodb_flush_log_at_trx_commit = 1
      innodb_file_per_table
      innodb_flush_method = O_DIRECT

      [mysqldump]
      quick
      quote-names
      max_allowed_packet = 16M

      [isamchk]
      key_buffer = 16M

      --SNIP--

        Gliffy Diagrams

          Attachments

            Activity

            Hide
            elenst Elena Stepanova added a comment -

            Re: MariaDB crashes on insert containing doubly nested subselect
            Hi Jason,

            Thank you for the report. The crash is reproducible on 5.5.23 just as you described it, but it seems to be gone in the current 5.5 tree. We had several fixes in this area, so it's likely to have been fixed along with them, but we'll double-check to make sure that it was not just masked.

            5.5.24 release is due this week.
            Meanwhile, as a workaround till you can upgrade, you might try to turn off derived_merge in your optimizer switch:
            optimizer_switch=derived_merge=off
            or, do it at runtime in the session which runs the query. Either should help.

            As a side note (not related to the crash), the query seems a bit risky – it only works properly if the innermost subquery returns exactly 1 row; if it returns nothing, the whole query fails because parent_platform_app_id cannot be null, and if there are multiple matches, it fails with ER_SUBQUERY_NO_1_ROW (subquery returns more than 1 row). Not sure if it's expected.

            Show
            elenst Elena Stepanova added a comment - Re: MariaDB crashes on insert containing doubly nested subselect Hi Jason, Thank you for the report. The crash is reproducible on 5.5.23 just as you described it, but it seems to be gone in the current 5.5 tree. We had several fixes in this area, so it's likely to have been fixed along with them, but we'll double-check to make sure that it was not just masked. 5.5.24 release is due this week. Meanwhile, as a workaround till you can upgrade, you might try to turn off derived_merge in your optimizer switch: optimizer_switch=derived_merge=off or, do it at runtime in the session which runs the query. Either should help. As a side note (not related to the crash), the query seems a bit risky – it only works properly if the innermost subquery returns exactly 1 row; if it returns nothing, the whole query fails because parent_platform_app_id cannot be null, and if there are multiple matches, it fails with ER_SUBQUERY_NO_1_ROW (subquery returns more than 1 row). Not sure if it's expected.
            Hide
            elenst Elena Stepanova added a comment -

            Re: MariaDB crashes on insert containing doubly nested subselect
            Sanja,

            This crash disappeared with revno 3505 on maria/5.3 tree (reproducible on 3504, not reproducible on 3505). Revno 3505 is the fix for bug #978847 which is also a crash on INSERT .. SELECT, although with a different stack trace. Could you please take a quick look at the trace above to confirm that your fix indeed fixed this problem also, not just hid it?
            If you need a test case, you can just use CREATE and INSERT .. SELECT provided in the description.

            Show
            elenst Elena Stepanova added a comment - Re: MariaDB crashes on insert containing doubly nested subselect Sanja, This crash disappeared with revno 3505 on maria/5.3 tree (reproducible on 3504, not reproducible on 3505). Revno 3505 is the fix for bug #978847 which is also a crash on INSERT .. SELECT, although with a different stack trace. Could you please take a quick look at the trace above to confirm that your fix indeed fixed this problem also, not just hid it? If you need a test case, you can just use CREATE and INSERT .. SELECT provided in the description.
            Hide
            ratzpo Rasmus Johansson added a comment -

            Launchpad bug id: 1000863

            Show
            ratzpo Rasmus Johansson added a comment - Launchpad bug id: 1000863
            Hide
            sanja Oleksandr Byelkin added a comment -

            It is duplicate of LP BUG#978847

            Show
            sanja Oleksandr Byelkin added a comment - It is duplicate of LP BUG#978847

              People

              • Assignee:
                sanja Oleksandr Byelkin
                Reporter:
                jasonvivian Jason Vivian
              • Votes:
                0 Vote for this issue
                Watchers:
                1 Start watching this issue

                Dates

                • Created:
                  Updated:
                  Resolved: