Bug #21206 | memory corruption when too many cursors are opened at once | ||
---|---|---|---|
Submitted: | 21 Jul 2006 8:31 | Modified: | 10 Aug 2006 15:44 |
Reporter: | Shane Bester (Platinum Quality Contributor) | Email Updates: | |
Status: | Closed | Impact on me: | |
Category: | MySQL Server: Prepared statements | Severity: | S1 (Critical) |
Version: | 5.0.22 | OS: | Any (*) |
Assigned to: | Tomash Brechko | CPU Architecture: | Any |
[21 Jul 2006 8:31]
Shane Bester
[21 Jul 2006 8:31]
MySQL Verification Team
lowering max_prepared_stmt_count is not an option as a fix. The server isn't out of memory. The point is that other connections are able to see table data in their results of SHOW.. statements!!!
[21 Jul 2006 8:37]
MySQL Verification Team
output from my ctestcase.c
Attachment: bugreport.txt (text/plain), 98.21 KiB.
[25 Jul 2006 19:09]
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/9546
[26 Jul 2006 9:23]
Konstantin Osipov
A workaround for this bug is to not use cursors. The bug itself occurs only when a connection has more than 1024 cursors (_not_ just prepared statements) open.
[26 Jul 2006 12:23]
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/9583
[27 Jul 2006 9:59]
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/9656
[27 Jul 2006 14:11]
Tomash Brechko
Pushed to 4.1.22 and 5.0.24.
[28 Jul 2006 4:26]
Paul DuBois
Noted in 4.1.22, 5.0.24 changelogs. 4.1.22: Under heavy load (executing more than 1024 simultaneous complex queries), a problem in the code that handles internal temporary tables could lead to writing beyond allocated space and memory corruption. 5.0.24: Under heavy load (executing more than 1024 simultaneous complex queries), a problem in the code that handles internal temporary tables could lead to writing beyond allocated space and memory corruption. Use of more than 1024 simultaneous cursors server wide also could lead to memory corruption. (This applies both to stored procedure and C API cursors.) Setting bug report back to NDI pending push of fix into 5.1.
[10 Aug 2006 10:22]
Tomash Brechko
Pushed to 5.1.12.
[10 Aug 2006 15:44]
Paul DuBois
Noted in 5.1.12 changelog.