| Bug #21856 | Prepared Statments: crash if bad create | ||
|---|---|---|---|
| Submitted: | 27 Aug 2006 23:50 | Modified: | 9 Nov 2006 15:19 |
| Reporter: | Peter Gulutzan | Email Updates: | |
| Status: | Closed | Impact on me: | |
| Category: | MySQL Server: Prepared statements | Severity: | S1 (Critical) |
| Version: | 5.1.12-beta-debug,5.0.24,5.0-BK | OS: | Linux (SUSE 10.0 / 64-bit, Linux 32-bit, Windows) |
| Assigned to: | Tomash Brechko | CPU Architecture: | Any |
[27 Aug 2006 23:50]
Peter Gulutzan
[28 Aug 2006 6:09]
MySQL Verification Team
5.0.24 5.0-BK, 5.1-BK all crashed on Linux/Windows. Sometimes the windows version crashed after multiple executions only. Bug #21847 might be related to this one.
[28 Aug 2006 6:10]
MySQL Verification Team
stack traces
Attachment: bug21856.txt (plain/text, text), 1.22 KiB.
[18 Sep 2006 9:27]
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/12110 ChangeSet@1.2261, 2006-09-18 13:25:58+04:00, kroki@moonlight.intranet +4 -0 BUG#21856: Prepared Statements: crash if bad create When statement to be prepared contained CREATE PROCEDURE, CREATE FUNCTION or CREATE TRIGGER statements with a syntax error in it, the preparation would fail with syntax error message, but the memory could be corrupted. The problem occurred because we switch memroot when parse stored routine or trigger definitions, and on parse error we restored the original memroot only after performing some memory operations. The solution is to restore memroot right after the failed parsing.
[21 Sep 2006 6:10]
Konstantin Osipov
Asked Tomash to try an alternative solution (although his patch is OK, the problematic piece of code is a source of many bugs, so we decided to try to simplify it).
[19 Oct 2006 9:59]
Konstantin Osipov
After exploring the alternative it's become clear that it's not feasible at this moment. Let's push the original patch instead.
[19 Oct 2006 10:45]
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/13965 ChangeSet@1.2261, 2006-10-19 14:43:52+04:00, kroki@moonlight.intranet +4 -0 BUG#21856: Prepared Statements: crash if bad create When statement to be prepared contained CREATE PROCEDURE, CREATE FUNCTION or CREATE TRIGGER statements with a syntax error in it, the preparation would fail with syntax error message, but the memory could be corrupted. The problem occurred because we switch memroot when parse stored routine or trigger definitions, and on parse error we restored the original memroot only after performing some memory operations. In more detail: - prepared statement would activate its own memory root to parse the definition of the stored procedure. - SP would reset this memory root with its own memory root to parse SP statements - a syntax error would happen - prepared statement would restore the original memory root - stored procedure would restore what it thinks was the original memory root, but actually was the statement memory root. That led to double free - in destruction of the statement and in a next call to mysql_parse(). The solution is to restore memroot right after the failed parsing.
[19 Oct 2006 13:29]
Tomash Brechko
Queued to 5.0-runtime and 5.1-runtime.
[9 Nov 2006 15:19]
Paul DuBois
Noted in 5.0.30 (not 5.0.29), 5.1.13 changelogs. Use of PREPARE with a CREATE PROCEDURE statement that contained a syntax error caused a server crash.
