Details

    • 10.0.21

    Description

      Hi,

      We crash the server when calling a stored procedure using cursors.

      I enclosed a dump of a small database that triggers the crash immediately when running:
      CALL BUG_MARIA_DB.T15_006467_Enrich_Pj_Postliv();

      This "small" database is a subset of a larger one that seems to be enough to trigger the crash. If it is not enough to reproduce the problem on your side, I can ask our DBA for more material.

      Best regards,
      Laurent

      Attachments

        Issue Links

          Activity

            Thanks for the report.

            Stack trace from 10.0 commit 36f37a4890a5407dc523fe6d1766e4dc2c57d70f

            10.0/sql/sql_acl.cc:10785: static const ACL_internal_schema_access* ACL_internal_schema_registry::lookup(const char*): Assertion `name != __null' failed.
            150613  1:36:16 [ERROR] mysqld got signal 6 ;
             
            #6  0x00007f83b92e0311 in *__GI___assert_fail (assertion=0xef672c "name != __null", file=<optimized out>, line=10785, function=0xef7d00 "static const ACL_internal_schema_access* ACL_internal_schema_registry::lookup(const char*)") at assert.c:81
            #7  0x0000000000610d12 in ACL_internal_schema_registry::lookup (name=0x0) at 10.0/sql/sql_acl.cc:10785
            #8  0x0000000000610dc8 in get_cached_schema_access (grant_internal_info=0x7f83a665a870, schema_name=0x0) at 10.0/sql/sql_acl.cc:10812
            #9  0x0000000000610e4b in get_cached_table_access (grant_internal_info=0x7f83a665a870, schema_name=0x0, table_name=0x0) at 10.0/sql/sql_acl.cc:10835
            #10 0x000000000060602f in check_grant (thd=0x7f83a0a01070, want_access=4, tables=0x7f83a665a5a0, any_combination_will_do=false, number=0, no_errors=true) at 10.0/sql/sql_acl.cc:6728
            #11 0x000000000068ad60 in multi_update_precheck (thd=0x7f83a0a01070, tables=0x7f83a67814a0) at 10.0/sql/sql_parse.cc:7758
            #12 0x000000000067f8b1 in mysql_execute_command (thd=0x7f83a0a01070) at 10.0/sql/sql_parse.cc:3325
            #13 0x00000000009aefbc in sp_instr_stmt::exec_core (this=0x7f83a67921e0, thd=0x7f83a0a01070, nextp=0x7f83bb49f9c8) at 10.0/sql/sp_head.cc:3204
            #14 0x00000000009ae70d in sp_lex_keeper::reset_lex_and_exec_core (this=0x7f83a6792220, thd=0x7f83a0a01070, nextp=0x7f83bb49f9c8, open_tables=false, instr=0x7f83a67921e0) at 10.0/sql/sp_head.cc:2971
            #15 0x00000000009aecc6 in sp_instr_stmt::execute (this=0x7f83a67921e0, thd=0x7f83a0a01070, nextp=0x7f83bb49f9c8) at 10.0/sql/sp_head.cc:3120
            #16 0x00000000009aaade in sp_head::execute (this=0x7f838e92b088, thd=0x7f83a0a01070, merge_da_on_success=true) at 10.0/sql/sp_head.cc:1371
            #17 0x00000000009ac78a in sp_head::execute_procedure (this=0x7f838e92b088, thd=0x7f83a0a01070, args=0x7f83a0a05670) at 10.0/sql/sp_head.cc:2159
            #18 0x0000000000683b76 in mysql_execute_command (thd=0x7f83a0a01070) at 10.0/sql/sql_parse.cc:4701
            #19 0x00000000006882ff in mysql_parse (thd=0x7f83a0a01070, rawbuf=0x7f83a662b088 "CALL T15_006467_Enrich_Pj_Postliv()", length=35, parser_state=0x7f83bb4a0650) at 10.0/sql/sql_parse.cc:6529
            #20 0x000000000067aceb in dispatch_command (command=COM_QUERY, thd=0x7f83a0a01070, packet=0x7f83a0af9071 "CALL T15_006467_Enrich_Pj_Postliv()", packet_length=35) at 10.0/sql/sql_parse.cc:1308
            #21 0x0000000000679fd1 in do_command (thd=0x7f83a0a01070) at 10.0/sql/sql_parse.cc:999
            #22 0x0000000000798093 in do_handle_one_connection (thd_arg=0x7f83a0a01070) at 10.0/sql/sql_connect.cc:1375
            #23 0x0000000000797de6 in handle_one_connection (arg=0x7f83a0a01070) at 10.0/sql/sql_connect.cc:1289
            #24 0x00007f83bb0dab50 in start_thread (arg=<optimized out>) at pthread_create.c:304
            #25 0x00007f83b939095d in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:112

            It appears to be the same as, or close to, MDEV-7971.
            There is definitely a multi-table update as well; no prepared statements, but there is a stored procedure instead, and they often share the same problems.

            Still, to be sure, this test case should be checked after MDEV-7971 is fixed.
            To reproduce,

            • start the server;
            • feed the attached SQL file to it;
            • run (assuming you fed the SQL file with the default database `test`)

              create user 'donzat_jld'@'%';
              grant all on test.* to 'donzat_jld'@'%';
              CALL T15_006467_Enrich_Pj_Postliv();

            elenst Elena Stepanova added a comment - Thanks for the report. Stack trace from 10.0 commit 36f37a4890a5407dc523fe6d1766e4dc2c57d70f 10.0/sql/sql_acl.cc:10785: static const ACL_internal_schema_access* ACL_internal_schema_registry::lookup(const char*): Assertion `name != __null' failed. 150613 1:36:16 [ERROR] mysqld got signal 6 ;   #6 0x00007f83b92e0311 in *__GI___assert_fail (assertion=0xef672c "name != __null", file=<optimized out>, line=10785, function=0xef7d00 "static const ACL_internal_schema_access* ACL_internal_schema_registry::lookup(const char*)") at assert.c:81 #7 0x0000000000610d12 in ACL_internal_schema_registry::lookup (name=0x0) at 10.0/sql/sql_acl.cc:10785 #8 0x0000000000610dc8 in get_cached_schema_access (grant_internal_info=0x7f83a665a870, schema_name=0x0) at 10.0/sql/sql_acl.cc:10812 #9 0x0000000000610e4b in get_cached_table_access (grant_internal_info=0x7f83a665a870, schema_name=0x0, table_name=0x0) at 10.0/sql/sql_acl.cc:10835 #10 0x000000000060602f in check_grant (thd=0x7f83a0a01070, want_access=4, tables=0x7f83a665a5a0, any_combination_will_do=false, number=0, no_errors=true) at 10.0/sql/sql_acl.cc:6728 #11 0x000000000068ad60 in multi_update_precheck (thd=0x7f83a0a01070, tables=0x7f83a67814a0) at 10.0/sql/sql_parse.cc:7758 #12 0x000000000067f8b1 in mysql_execute_command (thd=0x7f83a0a01070) at 10.0/sql/sql_parse.cc:3325 #13 0x00000000009aefbc in sp_instr_stmt::exec_core (this=0x7f83a67921e0, thd=0x7f83a0a01070, nextp=0x7f83bb49f9c8) at 10.0/sql/sp_head.cc:3204 #14 0x00000000009ae70d in sp_lex_keeper::reset_lex_and_exec_core (this=0x7f83a6792220, thd=0x7f83a0a01070, nextp=0x7f83bb49f9c8, open_tables=false, instr=0x7f83a67921e0) at 10.0/sql/sp_head.cc:2971 #15 0x00000000009aecc6 in sp_instr_stmt::execute (this=0x7f83a67921e0, thd=0x7f83a0a01070, nextp=0x7f83bb49f9c8) at 10.0/sql/sp_head.cc:3120 #16 0x00000000009aaade in sp_head::execute (this=0x7f838e92b088, thd=0x7f83a0a01070, merge_da_on_success=true) at 10.0/sql/sp_head.cc:1371 #17 0x00000000009ac78a in sp_head::execute_procedure (this=0x7f838e92b088, thd=0x7f83a0a01070, args=0x7f83a0a05670) at 10.0/sql/sp_head.cc:2159 #18 0x0000000000683b76 in mysql_execute_command (thd=0x7f83a0a01070) at 10.0/sql/sql_parse.cc:4701 #19 0x00000000006882ff in mysql_parse (thd=0x7f83a0a01070, rawbuf=0x7f83a662b088 "CALL T15_006467_Enrich_Pj_Postliv()", length=35, parser_state=0x7f83bb4a0650) at 10.0/sql/sql_parse.cc:6529 #20 0x000000000067aceb in dispatch_command (command=COM_QUERY, thd=0x7f83a0a01070, packet=0x7f83a0af9071 "CALL T15_006467_Enrich_Pj_Postliv()", packet_length=35) at 10.0/sql/sql_parse.cc:1308 #21 0x0000000000679fd1 in do_command (thd=0x7f83a0a01070) at 10.0/sql/sql_parse.cc:999 #22 0x0000000000798093 in do_handle_one_connection (thd_arg=0x7f83a0a01070) at 10.0/sql/sql_connect.cc:1375 #23 0x0000000000797de6 in handle_one_connection (arg=0x7f83a0a01070) at 10.0/sql/sql_connect.cc:1289 #24 0x00007f83bb0dab50 in start_thread (arg=<optimized out>) at pthread_create.c:304 #25 0x00007f83b939095d in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:112 It appears to be the same as, or close to, MDEV-7971 . There is definitely a multi-table update as well; no prepared statements, but there is a stored procedure instead, and they often share the same problems. Still, to be sure, this test case should be checked after MDEV-7971 is fixed. To reproduce, start the server; feed the attached SQL file to it; run (assuming you fed the SQL file with the default database `test`) create user 'donzat_jld' @ '%' ; grant all on test.* to 'donzat_jld' @ '%' ; CALL T15_006467_Enrich_Pj_Postliv();

            Confirm. This is the same problem as MDEV-7971. If I revert the fix for MDEV-7220, the crash in this bug goes away (however, we don't want to just revert that fix because it will cause a performance regression)

            psergei Sergei Petrunia added a comment - Confirm. This is the same problem as MDEV-7971 . If I revert the fix for MDEV-7220 , the crash in this bug goes away (however, we don't want to just revert that fix because it will cause a performance regression)
            psergei Sergei Petrunia added a comment - - edited

            Committed a patch for MDEV-7971. It's waiting for review and testing.

            psergei Sergei Petrunia added a comment - - edited Committed a patch for MDEV-7971 . It's waiting for review and testing.

            MDEV-7971 was fixed in 10.0.21, apparently this one can be closed too.

            elenst Elena Stepanova added a comment - MDEV-7971 was fixed in 10.0.21, apparently this one can be closed too.

            People

              psergei Sergei Petrunia
              lmahieux Laurent Mahieux
              Votes:
              0 Vote for this issue
              Watchers:
              4 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.