Bug #17892 MySQL leaks memory when service shuts down
Submitted: 3 Mar 2006 10:24 Modified: 15 Jan 2013 7:08
Reporter: d di (Basic Quality Contributor) Email Updates:
Status: Can't repeat Impact on me:
None 
Category:MySQL Server: General Severity:S3 (Non-critical)
Version:5.0.18/4.1/5.1 OS:Microsoft Windows (Windows)
Assigned to: Assigned Account CPU Architecture:Any
Tags: memory leak, qc

[3 Mar 2006 10:24] d di
Description:
MySQL causes the Service Control Manager (services.exe) to leak memory when MySQL is run as a Windows service and the service shuts itself down.

How to repeat:
Because the memory leak happens within an area that is allocated in advance of it's use, you'll have to exercise the memory leak multiple times before it will actually become visible.  When the preallocated area is full, a new area will be allocated and you'll see the memory counters increase.

First, make sure that MySQL shuts itself down immediately by faking the base directory in my.ini.  Just entering any non-existing directory should do.

Then type the following into a BAT file:
REM ==========================
:X
NET START MYSQL
GOTO X
REM ==========================

Start Task Manager and write down the value of the "VM Size" field for "services.exe".

Start an instance or two of the above BAT file and let it run for a couple of days.
Make sure that the machine is not doing anything else.

When you come back to the box after a day or two, the VM Size for services.exe should have increased.

On my box, it increases with an average rate of 4.75 bytes per second, in bundles of 24 kBytes, meaning that I see the first increase in VM size after ~90 minutes.

Suggested fix:
It would *probably* help to follow the Microsoft standard that defines how to communicate with the Service Control Manager.

Instead of terminating the MySQL server process with exit() when an error occurs, the MySQL main thread should notify MySQL's ServiceMain thread that it has terminated and whether an error has occurred.

The ServiceMain thread should then set the service status to STOPPED and if an error occurred, set the Win32ExitCode field to 1066 (service specific error) and the ServiceSpecificExitCode to something that the user can look up in the manual or with perror.

Then the ServiceMain thread should return, which in turn causes the service control command dispatcher thread (main application thread) to consider the service as being completely stopped, which will cause it to break out of StartServiceCtrlDispatcher, which in turn will cause the MySQL process to exit out of main() in a controlled fashion.
[23 Mar 2006 12:26] Valeriy Kravchuk
Thank you for a problem report. Please, specify the exact Windows version used. I have no services.exe at all on my 64-bit XP Pro.
[23 Mar 2006 12:28] d di
I've tested on Windows XP Pro SP2 on 32-bit x86 hardware.
[29 Mar 2006 14:17] MySQL Verification Team
Thank you for the bug report. I was able to repeat as reported in some
minutes looking the memory usage of service.exe in the Task manager
and running the batch file.
[15 Jan 2013 7:08] Erlend Dahl
This is no longer reproducible.