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:
None 
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
Description:
After about 1500 statements have not been closed using mysql_stmt_close(), memory corruption and crashes can be seen.

The corruption is seen easily by running SHOW GLOBAL VARIABLES or other SHOW statements after the testcase.  It is also manifested in incorrect results from other statements, if you have multiple statements open in the program.

On Windows, mysqld-nt 5.0.22 crashed immediately during my testcase.  On fc4 mysql-max-5.0.22 didn't crash, but instead had corruption of memory.  On FC4, a 5.0bk build froze and had to be killed by kill -9.  

Different OS's/builds may behave differently. 

How to repeat:
Start mysqld using all defaults.

Build and run the attached ctestcase.c program to demostrate the problem.

$ gcc ctestcase.c -g -o ctestcase -L/home/sbester/servers/5.0-bk/lib -I/home/sbester/servers/5.0-bk/include  -lmysqlclient_r -lz -lpthread 

$ ./ctestcase 127.0.0.1 3306 test root > bugreport.txt

See content of bugreport.txt

<snip>
[INFO]  ctestcase.c:155 - Connected....
[INFO]  ctestcase.c:157 - Running 10000 loops closing each stmt afterwards
[INFO]  ctestcase.c:163 - Running 1500 loops NOT closing each stmt afterwards
[INFO]  ctestcase.c:170 - Running SHOW GLOBAL VARIABLES
..
autt_timeout	28800	
autt_timeout	28800	
autt_timeout	28800	
chat_timeout	28800	
chat_timeout	28800	
..
nett_timeout	28800	
new	28800	
oldt_timeout	28800	
opet_timeout	28800	
optt_timeout	28800	
optt_timeout	28800	
pidt_tim	28800	
pret_timeout	28800	
port	28800	
...
</snip>

Suggested fix:
not sure..
[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.