Bug #17290 SP with delete, create and rollback to save point causes MySQLD core
Submitted: 9 Feb 2006 21:54 Modified: 24 Mar 2006 13:51
Reporter: Jonathan Miller Email Updates:
Status: Closed Impact on me:
None 
Category:MySQL Server: Partitions Severity:S1 (Critical)
Version:5.1.7 OS:Linux (Linux 32 Bit OS)
Assigned to: Alexey Botchkov CPU Architecture:Any

[9 Feb 2006 21:54] Jonathan Miller
Description:
Seems that multipal calls to SP with delete, create and the rollback to save point cause this core. I could not break is down to less then that. 

#0  0x00342402 in __kernel_vsyscall ()
#1  0x00a2855f in pthread_kill () from /lib/libpthread.so.0
#2  0x082eeb3b in write_core (sig=32669) at stacktrace.c:220
#3  0x081d1a22 in handle_segfault (sig=11) at mysqld.cc:2197
#4  <signal handler called>
#5  ha_ndbcluster::set_up_partition_info (this=0x96e54e8, part_info=0x96e63e8,
    table=0x86df8d24, tab_par=0x518b70) at sql_list.h:380
#6  0x083400e7 in ha_ndbcluster::create (this=0x96e54e8, name=0x519998 "./test/t1",
    form=0x518bcc, info=0x96d4498) at ha_ndbcluster.cc:4329
#7  0x082a3678 in ha_create_table (thd=0x96814a0,
    path=0x86df8d24 <Address 0x86df8d24 out of bounds>, db=0x96cc720 "test",
    table_name=0x96cc728 "t1", create_info=0x96d4498, update_create_info=false)
    at handler.cc:2186
#8  0x082855cc in rea_create_table (thd=0x96814a0, path=0x519998 "./test/t1",
    db=0x96cc720 "test", table_name=0x96cc728 "t1", create_info=0x96d4498,
    create_fields=@0x86df8d24, keys=2262797604, key_info=0x86df8d24, file=0x96ec418)
    at unireg.cc:335
#9  0x082b4c23 in mysql_create_table (thd=0x96814a0, db=0x96cc720 "test",
    table_name=0x96cc728 "t1", create_info=0x96d4498, fields=@0x96d43bc, keys=@0x96d43b0,
    internal_tmp_table=false, select_field_count=2262797604) at sql_table.cc:2246
#10 0x081f4b0a in mysql_execute_command (thd=0x96814a0) at sql_parse.cc:2902
#11 0x082fff81 in sp_instr_stmt::exec_core (this=0x0, thd=0x86df8d24, nextp=0x0)
    at sp_head.cc:2328
#12 0x0830059a in sp_lex_keeper::reset_lex_and_exec_core (this=0x96cc9d4, thd=0x96814a0,
    nextp=0x86df8d24, open_tables=false, instr=0x96cc9b0) at sp_head.cc:2207
#13 0x083045c7 in sp_instr_stmt::execute (this=0x96cc9b0, thd=0x96814a0, nextp=0x51a7e0)
#14 0x08302e89 in sp_head::execute (this=0x96cbf38, thd=0x96814a0) at sp_head.cc:1074
#15 0x08303564 in sp_head::execute_procedure (this=0x96cbf38, thd=0x96814a0, args=0x9681974)
    at sp_head.cc:1520
#16 0x081f36a2 in mysql_execute_command (thd=0x96814a0) at sql_parse.cc:4385
#17 0x081f50b4 in mysql_parse (thd=0x96814a0, inBuf=0x968ce48 "CALL test.p1(13)", length=16)
    at sql_parse.cc:5719
#18 0x081f567d in dispatch_command (command=COM_QUERY, thd=0x96814a0, packet=Variable "packet" is not available.
)
    at sql_parse.cc:1769
#19 0x081f7407 in handle_one_connection (arg=0x96814a0) at sql_parse.cc:1536
#20 0x00a25b80 in start_thread () from /lib/libpthread.so.0
#21 0x002139ce in clone () from /lib/libc.so.6

How to repeat:
let $engine_type=NDBCLUSTER;
delimiter |;
eval CREATE PROCEDURE test.p1(IN i INT)
BEGIN
  DECLARE CONTINUE HANDLER FOR sqlexception BEGIN END;
  DROP TABLE IF EXISTS test.t1;
  CREATE TABLE test.t1 (num INT,PRIMARY KEY(num))ENGINE=$engine_type;
  START TRANSACTION;
    INSERT INTO test.t1 VALUES(i);
    savepoint t1_save;
    INSERT INTO test.t1 VALUES (14);
    ROLLBACK to savepoint t1_save;
    COMMIT;
END|
delimiter ;|
CALL test.p1(12);
CALL test.p1(13);
[10 Feb 2006 9:58] Tomas Ulin
moving to be a partiton bug as the issue is the same if create table is

engine=innodb partition by key(num)
[25 Feb 2006 18:08] Bugs System
A patch for this bug has been committed. After review, it may
be pushed to the relevant source trees for release in the next
version. You can access the patch from:

  http://lists.mysql.com/commits/3141
[13 Mar 2006 13:59] Mikael Ronström
Nope, this won't solve the problem. It's necessary to save a partition_info object as it
was after the parser executed it in order to fix this type of issues with prepared statements
and stored procedures
[20 Mar 2006 23:15] Mikael Ronström
This patch will appear in 5.1.8
Calling CREATE TABLE/ALTER TABLE on partitioned table in prepared statement
two times after each other, within a stored procedure led to this and many other
duplicate bugs.
[20 Mar 2006 23:22] Mikael Ronström
Clarification of comment for documenting.
Calling a create/alter table twice in a stored procedure on partitioned table
got this problem as well as
a prepared statement as above that was called at least twice.
The errors were sometimes crashing and sometimes not.
[24 Mar 2006 13:51] Jon Stephens
Thank you for your bug report. This issue has been committed to our
source repository of that product and will be incorporated into the
next release.

If necessary, you can access the source repository and build the latest
available version, including the bugfix, yourself. More information 
about accessing the source trees is available at
    http://www.mysql.com/doc/en/Installing_source_tree.html

Additional info:

Documented bugfix in 5.1.8 changelog. Closed.