[MDEV-8309] Stored procedure crashes server Created: 2015-06-12  Updated: 2015-10-20  Resolved: 2015-10-20

Status: Closed
Project: MariaDB Server
Component/s: Data Manipulation - Subquery, Data Manipulation - Update
Affects Version/s: 10.0.19
Fix Version/s: 10.0.21

Type: Bug Priority: Critical
Reporter: Laurent Mahieux Assignee: Sergei Petrunia
Resolution: Fixed Votes: 0
Labels: crash, stored_procedures
Environment:

Debian 7.8 ; running mariaDB server 10.0.19+maria-1~wheezy

Attachments: File BUG_MARIA_DB.sql.bz2    
Issue Links:
Relates
relates to MDEV-7971 Assertion `name != __null' failed in ... Closed
Sprint: 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

 Comments   
Comment by Elena Stepanova [ 2015-06-13 ]

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();

Comment by Sergei Petrunia [ 2015-07-27 ]

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)

Comment by Sergei Petrunia [ 2015-07-28 ]

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

Comment by Elena Stepanova [ 2015-10-20 ]

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

Generated at Thu Feb 08 07:26:11 UTC 2024 using Jira 8.20.16#820016-sha1:9d11dbea5f4be3d4cc21f03a88dd11d8c8687422.