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

Assertion `count > 0' failed in Item_sum_sum::add_helper(bool)

Details

    Description

      mysqld: /src/10.2/sql/item_sum.cc:1339: void Item_sum_sum::add_helper(bool): Assertion `count > 0' failed.
      160521 19:34:51 [ERROR] mysqld got signal 6 ;
      

      #7  0x00007f994920c1d2 in __assert_fail () from /lib64/libc.so.6
      #8  0x000055c4a846f1b0 in Item_sum_sum::add_helper (this=0x7f993f867538, perform_removal=true) at /src/10.2/sql/item_sum.cc:1339
      #9  0x000055c4a846f7d8 in Item_sum_sum::remove (this=0x7f993f867538) at /src/10.2/sql/item_sum.cc:1426
      #10 0x000055c4a847041a in Item_sum_avg::remove (this=0x7f993f867538) at /src/10.2/sql/item_sum.cc:1685
      #11 0x000055c4a831c792 in Frame_range_n_top::walk_till_non_peer (this=0x7f993f86b8b8, item=0x7f993f867538) at /src/10.2/sql/sql_window.cc:915
      #12 0x000055c4a831c676 in Frame_range_n_top::next_partition (this=0x7f993f86b8b8, rownum=0, item=0x7f993f867538) at /src/10.2/sql/sql_window.cc:884
      #13 0x000055c4a831add6 in compute_window_func_with_frames (item_win=0x7f993f867cd8, tbl=0x7f993f96d088, info=0x7f994b4d9340) at /src/10.2/sql/sql_window.cc:1729
      #14 0x000055c4a831b219 in Window_func_runner::exec (this=0x7f993f86adc0, tbl=0x7f993f96d088, filesort_result=0x7f993f701000) at /src/10.2/sql/sql_window.cc:1860
      #15 0x000055c4a831b305 in Window_funcs_sort::exec (this=0x7f993f86ad98, join=0x7f993f868618) at /src/10.2/sql/sql_window.cc:1887
      #16 0x000055c4a831b6b6 in Window_funcs_computation::exec (this=0x7f993f86ad78, join=0x7f993f868618) at /src/10.2/sql/sql_window.cc:1969
      #17 0x000055c4a81ec57c in AGGR_OP::end_send (this=0x7f993f86aa40) at /src/10.2/sql/sql_select.cc:25992
      #18 0x000055c4a81d8625 in sub_select_postjoin_aggr (join=0x7f993f868618, join_tab=0x7f993f869ca0, end_of_records=true) at /src/10.2/sql/sql_select.cc:17973
      #19 0x000055c4a81d8913 in sub_select (join=0x7f993f868618, join_tab=0x7f993f8698f8, end_of_records=true) at /src/10.2/sql/sql_select.cc:18209
      #20 0x000055c4a81d81a5 in do_select (join=0x7f993f868618, procedure=0x0) at /src/10.2/sql/sql_select.cc:17803
      #21 0x000055c4a81b41e6 in JOIN::exec_inner (this=0x7f993f868618) at /src/10.2/sql/sql_select.cc:3342
      #22 0x000055c4a81b3766 in JOIN::exec (this=0x7f993f868618) at /src/10.2/sql/sql_select.cc:3154
      #23 0x000055c4a81b4866 in mysql_select (thd=0x7f993f82dc30, tables=0x7f993f867f20, wild_num=0, fields=..., conds=0x0, og_num=0, order=0x0, group=0x0, having=0x0, proc_param=0x0, select_options=2147748608, result=0x7f993f8685f8, unit=0x7f993f831680, select_lex=0x7f993f831da8) at /src/10.2/sql/sql_select.cc:3538
      #24 0x000055c4a81aa0b0 in handle_select (thd=0x7f993f82dc30, lex=0x7f993f8315b8, result=0x7f993f8685f8, setup_tables_done_option=0) at /src/10.2/sql/sql_select.cc:377
      #25 0x000055c4a8179a47 in execute_sqlcom_select (thd=0x7f993f82dc30, all_tables=0x7f993f867f20) at /src/10.2/sql/sql_parse.cc:6318
      #26 0x000055c4a816f74c in mysql_execute_command (thd=0x7f993f82dc30) at /src/10.2/sql/sql_parse.cc:3356
      #27 0x000055c4a817d110 in mysql_parse (thd=0x7f993f82dc30, rawbuf=0x7f993f867188 "select o_custkey, Avg(o_custkey) OVER (PARTITION BY abs(o_custkey) ORDER BY o_custkey RANGE BETWEEN 15 FOLLOWING AND 15 FOLLOWING) from orders", length=142, parser_state=0x7f994b4da9e0, is_com_multi=false, is_next_command=false) at /src/10.2/sql/sql_parse.cc:7730
      #28 0x000055c4a816b561 in dispatch_command (command=COM_QUERY, thd=0x7f993f82dc30, packet=0x7f993f8611f1 "", packet_length=142, is_com_multi=false, is_next_command=false) at /src/10.2/sql/sql_parse.cc:1794
      #29 0x000055c4a8169fa0 in do_command (thd=0x7f993f82dc30) at /src/10.2/sql/sql_parse.cc:1355
      #30 0x000055c4a82a043a in do_handle_one_connection (connect=0x7f9948c84310) at /src/10.2/sql/sql_connect.cc:1358
      #31 0x000055c4a82a01cc in handle_one_connection (arg=0x7f9948c84310) at /src/10.2/sql/sql_connect.cc:1264
      #32 0x000055c4a89b55f6 in pfs_spawn_thread (arg=0x7f99441c6ff0) at /src/10.2/storage/perfschema/pfs.cc:1862
      #33 0x00007f994b1550a4 in start_thread () from /lib64/libpthread.so.0
      #34 0x00007f99492c304d in clone () from /lib64/libc.so.6
      

      CREATE TABLE `orders` (
        `o_orderkey` int(11) NOT NULL,
        `o_custkey` int(11) DEFAULT NULL,
        `o_orderstatus` char(1) DEFAULT NULL,
        `o_totalprice` double DEFAULT NULL,
        `o_orderDATE` date DEFAULT NULL,
        `o_orderpriority` char(15) DEFAULT NULL,
        `o_clerk` char(15) DEFAULT NULL,
        `o_shippriority` int(11) DEFAULT NULL,
        `o_comment` varchar(79) DEFAULT NULL,
        PRIMARY KEY (`o_orderkey`),
        KEY `i_o_orderdate` (`o_orderDATE`),
        KEY `i_o_custkey` (`o_custkey`)
      ) DEFAULT CHARSET=latin1; 
       
      INSERT INTO `orders` VALUES (59908,242,'F',33695.83,'1992-09-26','1-URGENT','Clerk#000000016',0,'furiously pending requests wake sly');
      INSERT INTO `orders` VALUES (59940,238,'F',130910.25,'1994-09-25','5-LOW','Clerk#000000515',0,'ironic, ironic packages cajole slyly across the regular, bold d');
       
      select o_custkey, Avg(o_custkey) OVER (PARTITION BY abs(o_custkey) ORDER BY o_custkey RANGE BETWEEN 15 FOLLOWING AND 15 FOLLOWING) from orders;
      

      Attachments

        Issue Links

          Activity

            Hi Sergei!

            I have a fix for this issue. Please review it here:

            https://github.com/MariaDB/server/commit/4d1e032458c7cb591da77ad576a8694fe65dddb6

            The reasoning is explained in the commit message. Note that this is on top of my cursors refactoring, so that's why Frame_cursor constructors are slightly different. The logic concerning this bug however applies to the previous version as well.

            Thanks,
            Vicentiu

            cvicentiu Vicențiu Ciorbaru added a comment - Hi Sergei! I have a fix for this issue. Please review it here: https://github.com/MariaDB/server/commit/4d1e032458c7cb591da77ad576a8694fe65dddb6 The reasoning is explained in the commit message. Note that this is on top of my cursors refactoring, so that's why Frame_cursor constructors are slightly different. The logic concerning this bug however applies to the previous version as well. Thanks, Vicentiu

            Sergey,
            I can't reproduce this bug.
            Maybe it has been fixed? If so please close the issue.

            igor Igor Babaev (Inactive) added a comment - Sergey, I can't reproduce this bug. Maybe it has been fixed? If so please close the issue.

            It was fixed in 10.2.2 by this commit:

            commit 1adc3fab23c76cad3ac246075357228d544c6dd4
            Author: Vicențiu Ciorbaru <vicentiu@mariadb.org>
            Date:   Sun Sep 4 05:51:10 2016 +0300
             
                MDEV-10097: Assertion `count > 0' failed in Item_sum_sum::add_helper(bool)
                
                When specifying a RANGE type frame that exceeds the partition size, both
                for the top and bottom cursors we end up removing more rows than added
                to the aggregate function. This happens because our TOP range cursor,
                which removes values from the aggregate function, would be allowed to breach
                partition boundaries, while the BOTTOM range cursor would not.
                
                To prevent this from happening, force the TOP range cursor to only move
                within the current partition, as does the BOTTOM range cursor.
            

            elenst Elena Stepanova added a comment - It was fixed in 10.2.2 by this commit: commit 1adc3fab23c76cad3ac246075357228d544c6dd4 Author: Vicențiu Ciorbaru <vicentiu@mariadb.org> Date: Sun Sep 4 05:51:10 2016 +0300   MDEV-10097: Assertion `count > 0' failed in Item_sum_sum::add_helper(bool) When specifying a RANGE type frame that exceeds the partition size, both for the top and bottom cursors we end up removing more rows than added to the aggregate function. This happens because our TOP range cursor, which removes values from the aggregate function, would be allowed to breach partition boundaries, while the BOTTOM range cursor would not. To prevent this from happening, force the TOP range cursor to only move within the current partition, as does the BOTTOM range cursor.

            People

              cvicentiu Vicențiu Ciorbaru
              elenst Elena Stepanova
              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.