Bug #34778 Possible memory leak running UPDATEs in tight loop
Submitted: 23 Feb 2008 19:03 Modified: 9 Oct 2008 13:43
Reporter: Hakan Kuecuekyilmaz
Status: Closed
Category:Server: Falcon Severity:S3 (Non-critical)
Version:6.0.4, mysql-6.0-falcon-team OS:Any
Assigned to: Christopher Powers Target Version:6.0.5
Tags: F_SCAVENGER
Triage: D2 (Serious)

[23 Feb 2008 19:03] Hakan Kuecuekyilmaz 
Description:
Running falcon_record_cache_memory_leak2-big shows steady increase in Falcon's memory
usage.

How to repeat:
Run falcon_record_cache_memory_leak2-big from mysql-6.0-falcon team tree with --big-test
option.

./mysql-test-run.pl --big-test --force  --suite=falcon
falcon_record_cache_memory_leak2-big

mysqld memory usage starts around 170MB and increases until around 420MB where we get a 

mysqltest: At line 45: query 'UPDATE t1 SET c1 = upper(c1)' failed: 1296: Got error 305
'record memory is exhausted' from Falcon.

Please note that the transaction in the test do not change the rows in question. Every
transaction ends in way so that the values are the same as before.
[25 Feb 2008 17:13] Ann Harrison 
I'm not at all sure this is a bug...  even an update that sets values
to itself does create new record versions.  Until the backlog is in
place, that can fill memory.
[25 Feb 2008 17:23] Hakan Kuecuekyilmaz 
We have run this test lot's of times already. The memory consumption got stable after
Kevin had fixed couple of memory leaks.
[30 Mar 2008 9:26] 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/44649

ChangeSet@1.2623, 2008-03-30 02:24:29-05:00, cpowers@xeno.mysql.com +8 -0
  Bug#34778, "Possible memory leak running UPDATEs in tight loop"
  
  This test generates thousands of prior record versions for just a
  very few records. The record scavenger ignored the prior record chain
  because the base record was not a scavenge candidate.
  
  The scavenger now scavenges prior records that match the transaction and
  record generation criteria, even when the base record is not scavengable.
[10 Apr 2008 21:14] Bugs System 
Pushed into 6.0.5-alpha
[9 Oct 2008 13:43] Jon Stephens 
Documented in the 6.0.5 changelog as follows:

        Repeated UPDATE operations on a Falcon table could cause a memory leak.