MySQL Bugs: #23527: set global query_cache_size can crash the server under high load

Bug #23527	set global query_cache_size can crash the server under high load
Submitted:	21 Oct 2006 19:28	Modified:	8 Mar 2007 3:11
Reporter:	Shane Bester (Platinum Quality Contributor)	Email Updates:
Status:	Closed	Impact on me:	None
Category:	MySQL Server: General	Severity:	S1 (Critical)
Version:	5.0.26, 5.0BK, 5.1-BK,	OS:	Linux (Suse 9.3, windows x86)
Assigned to:	Tomash Brechko	CPU Architecture:	Any
Tags:	query cache crash query_cache_size, rt_q1_2007

Description:
"set global query_cache_size = .. " can crash mysqld if the server is under relatively high load.  

Opening as a new bug report, because there's a straight-forward testcase here.

Backtrace looks like this:

Stack range sanity check OK, backtrace follows:
0x817adf8 handle_segfault + 356
0x824c7d6 _ZN11Query_cache6resizeEm + 138
0x81873a4 _Z20fix_query_cache_sizeP3THD13enum_var_type + 24
0x818a2c5 _ZN7set_var6updateEP3THD + 69
0x8189fca _Z17sql_set_variablesP3THDP4ListI12set_var_baseE + 122
0x8191101 _Z21mysql_execute_commandP3THD + 6489
0x8196a02 _Z11mysql_parseP3THDPcj + 306
0x818e2a6 _Z16dispatch_command19enum_server_commandP3THDPcj + 1182
0x818ddcd _Z10do_commandP3THD + 129
0x818d4c4 handle_one_connection + 620
0x40040aa7 _end + 933727415
0x40175c2e _end + 934993470

How to repeat:
compile and run the attached testcase.c. See top of file for gcc instructions.

Suggested fix:
.

see top of file for compiling instructions.

Attachment: testcase.c (text/x-csrc), 4.76 KiB.

stacks from mysqld-debug on windows

Attachment: 5.0.26_windows_stacktrace.txt (plain/text, text), 1.92 KiB.

marked bug #21256 as duplicate of this

Hello Shane,

I believe I found the cause of the bug, and have the fix for it.  However I see it as a regression introduced with my fix of bug#21051.  So we have some mismatches:

1 Being the result of the fix of bug#21051 this bug can't be a duplicate of bug#21256, as I was able to repeat the latter _before_ the push of the fix for bug#21051 (I wouldn't push otherwise).  As we don't have an explicit evidence that they are duplicates I'm going to unlink them.

2 You list 4.0BK, 4.1BK in 'Version:' field for this bug, however bug#21051 was pushed into 5.0 and up only.  Besides, I was unable to compile your provided C test case with 4.0 (didn't try 4.1 though).  So, how can I verify the bug is in 4.0 and 4.1 (which will break my nice theory about relation with bug#21051 :-)), or maybe it's just a typo?

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/18522

ChangeSet@1.2320, 2007-01-22 13:03:38+03:00, kroki@moonlight.home +1 -0
  BUG#23527: set global query_cache_size can crash the server under
             high load
  
  MySQL server could crash if two or more threads would initiate query
  cache resize at the moments very close in time.
  
  The problem was introduced with the fix of bug 21051 in 5.0 and 5.1:
  simultaneous query cache resizes would wait for the first one in
  progress, but then each thread would try to finish the operation,
  accessing the data that was already reset (attempt to dereference
  'bins' pointer, which may be NULL already).
  
  The solution is to check after synchronization if another thread has
  done the reset already (test 'query_cache_size > 0' again).
  
  No test case is provided because the bug is a subject to a race.

Reviewed by email and IRC, approved.

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/18790

ChangeSet@1.2320, 2007-01-25 20:00:12+03:00, kroki@moonlight.home +1 -0
  BUG#23527: set global query_cache_size can crash the server under
             high load
  
  MySQL server could crash if two or more threads would initiate query
  cache resize at the moments very close in time.
  
  The problem was introduced with the fix of bug 21051 in 5.0 and 5.1:
  simultaneous query cache resizes would wait for the first one in
  progress, but then each thread would try to finish the operation,
  accessing the data that was already reset (attempt to dereference
  'bins' pointer, which may be NULL already).
  
  The solution is to check after synchronization if another thread has
  done the reset already (test 'query_cache_size > 0' again).
  
  No test case is provided because the bug is a subject to a race.

Queued to 5.0-runtime and 5.1-runtime.

Updating version field, as the bug fixed was only in 5.0 and 5.1.

Pushed into 5.0.38 and 5.1.17.

Noted in 5.0.38, 5.1.17 changelogs.