MySQL Bugs: #21206: memory corruption when too many cursors are opened at once

Bug #21206	memory corruption when too many cursors are opened at once
Submitted:	21 Jul 2006 10:31	Modified:	10 Aug 2006 17:44
Reporter:	Shane Bester
Status:	Closed
Category:	Server: PS	Severity:	S1 (Critical)
Version:	5.0.22	OS:	Any (*)
Assigned to:	Bugs System	Target Version:

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..

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!!!

output from my ctestcase.c

Attachment: bugreport.txt (text/plain), 98.21 KiB.

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

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.

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

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

Pushed to 4.1.22 and 5.0.24.

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.

Pushed to 5.1.12.

Noted in 5.1.12 changelog.