| Bug #12637 | SP crashes the server if it has update query with user var & binlog is enabled | ||
|---|---|---|---|
| Submitted: | 18 Aug 2005 9:01 | Modified: | 9 Sep 2005 18:10 |
| Reporter: | Petr Chardin | Email Updates: | |
| Status: | Closed | Impact on me: | |
| Category: | MySQL Server: Replication | Severity: | S3 (Non-critical) |
| Version: | 5.0 | OS: | |
| Assigned to: | Sergey Petrunya | CPU Architecture: | Any |
[18 Aug 2005 12:08]
MySQL Verification Team
Verified on Linux with 5.0.12-beta-debug-log
[7 Sep 2005 15:38]
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/internals/29437
[9 Sep 2005 8:13]
Sergey Petrunya
Fix pushed into 5.0.13 tree. Notes for the changelog: the bug as follows: If binary log was enabled, running an SP that modifies table data and uses user variables could cause crash or wrong info written to binary log.
[9 Sep 2005 18:10]
Paul DuBois
Noted in 5.0.13 changelog.

Description: Server crashes if one executes a stored procedure, wich has an update query with user variables and binlog is enabled. Note: For some reason crash happens only on LinuxThreads. Systems with NPTL do not crash. So, one should use LD_ASSUME_KERNEL=2.5 env. var to reproduce the crash, if his distro has NPTL by default (E.g. Suse) How to repeat: use this test (which is currenly disabled in sp.test) drop table if exists t1; create table t1 ( id char(16) not null default '', data int not null ); delimiter |; --disable_warnings drop procedure if exists bug12297| --enable_warnings create procedure bug12297(lim int) begin set @x = 0; repeat insert into t1(id,data) values('aa', @x); set @x = @x + 1; until @x >= lim end repeat; end| call bug12297(10)| drop procedure bug12297| delimiter ;| Suggested fix: This happens at sql_parse.cc:4248 -- else { thd->clear_error(); Query_log_event qinfo(thd, thd->query, thd->query_length, 0, FALSE); mysql_bin_log.write(&qinfo); } Looks like the reason is get_var_with_binlog(), which is invoked from SP. It allocates memory on SP's internal arena, which is destroyed after SP is executed. Problably we should check wheter we are in the SP, and switch to the right arena then.