Bug #16175 memory leak in rpl_trigger.test
Submitted: 4 Jan 2006 7:43 Modified: 2 Mar 2006 15:13
Reporter: Sergei Golubchik Email Updates:
Status: Closed Impact on me:
None 
Category:MySQL Server: Replication Severity:S3 (Non-critical)
Version:5.0 OS:
Assigned to: Alexander Ivanov CPU Architecture:Any

[4 Jan 2006 7:43] Sergei Golubchik
Description:
Warning: Not freed memory segments: 2
Warning: Memory that was not free'ed (11 bytes):
             6 bytes at 0x009120098, allocated at line 1095 in 'sql_db.cc'
             5 bytes at 0x009120058, allocated at line 1095 in 'sql_db.cc'

probably caused by http://lists.mysql.com/commits/65

How to repeat:
build with safemalloc, run rpl_trigger.test
[28 Feb 2006 17:15] Beat Vontobel
I possibly just ran into this bug: I executed an INSERT INTO a SELECT ... FROM b on the master with a result set of about 22 million rows and a complex trigger on table a. The query took about 47 minutes to execute on the master but everything worked fine. Now on the slave there seems to be a bad memory leak: mysqld slowly eats up more and more memory, starts to swap and finally gets killed by the kernel. Could this be this bug? (I never had similar problems with similar queries without triggers on the target table and never had any problems with inserts of smaller result sets even with triggers.)

As the affected system is in full production I'm now mainly concerned to find a quick workaround. But I'll get back to you later. I'd just be happy if you could tell me if this could be the same bug (then I think it should be S1) or I should file another one. Currently running 5.0.18 on both master and slave on Linux.
[1 Mar 2006 10:11] 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/3304
[2 Mar 2006 11:53] Alexander Ivanov
Fixed in 5.0.19
[2 Mar 2006 12:56] Alexander Ivanov
Fixed in 5.1.8-beta, 5.2.0-alpha
[2 Mar 2006 15:13] Paul Dubois
Noted in 5.0.19, 5.1.8 changelogs.

A memory leak caused warnings on slaves for certain statements
that executed without warning on the master. (Bug #16175)