Description:
There seems to be memory leaks, when using the "libmysql.dll" (C-API). They occure between the first call of 'mysql_init' and the 'mysql_close' - even when I enclose these commands between 'mysql_thread_start' and 'mysql_thread_end' I get even more memory leaks.
I compiled the sources of libmysql into a DEBUG version, otherwise I didn't get them (the standard DLL delivered with a standard release of mysql is a RELEASE version, with that the debugger will not report any memory leaks).
The leaks seems to exist, even without calling any other api-function (like a connect or a query).
I'm developping a custom OLE-DB provider for MySQL to be used in VBA (I still have an "old fashioned" Access97, MyODBC doesn't always work - specially with BLOB's while they are written good via MyODBC but read incorrect - so that's why I wrote a fix via my custom provider).
Following is a snippet of the debug-report from inside MS-VisualC++ :
<...snip...>
LDR: Automatic DLL Relocation in Msaccess.exe
LDR: Dll LIBMYSQL.dll base 10000000 relocated due to collision with C:\Program Files\Logitech\MouseWare\System\LgWndHk.dll
Loaded symbols for 'D:\Data\ActiveX\lkMySQL\Debug\libmysql.dll'
Loaded 'C:\WINNT\system32\WSOCK32.DLL', no matching symbolic information found.
Loaded 'C:\WINNT\system32\WS2_32.DLL', no matching symbolic information found.
Loaded 'C:\WINNT\system32\WS2HELP.DLL', no matching symbolic information found.
Loaded symbols for 'C:\WINNT\system32\MSVCRTD.DLL'
Loaded symbols for 'C:\WINNT\system32\MFC42D.DLL'
Loaded symbols for 'C:\WINNT\system32\MFCO42D.DLL'
Loaded 'C:\WINNT\system32\RNR20.DLL', no matching symbolic information found.
Loaded 'C:\WINNT\system32\RPCLTC1.DLL', no matching symbolic information found.
The thread 0xB7 has exited with code 0 (0x0).
The thread 0xB6 has exited with code 0 (0x0).
The thread 0xB2 has exited with code 0 (0x0).
The thread 0x5E has exited with code 0 (0x0).
Info: AfxDllCanUnloadNow returning S_OK
Info: AfxDllCanUnloadNow returning S_OK
The thread 0xB0 has exited with code 0 (0x0).
The thread 0x2D has exited with code 0 (0x0).
Detected memory leaks!
Dumping objects ->
{78} normal block at 0x09381CF0, 92 bytes long.
Data: < ˜ ¨É > 00 00 00 00 00 00 00 00 98 01 00 00 A8 C9 17 00
{48} normal block at 0x093722C0, 556 bytes long.
Data: < È > 00 00 00 00 C8 00 00 00 00 00 00 00 00 00 00 00
Object dump complete.
The thread 0xBA has exited with code 0 (0x0).
The thread 0x9C has exited with code 0 (0x0).
The thread 0xB5 has exited with code 0 (0x0).
The thread 0x61 has exited with code 0 (0x0).
The thread 0x52 has exited with code 0 (0x0).
The program 'E:\Program Files\Microsoft Office\Office\Msaccess.exe' has exited with code 0 (0x0).
How to repeat:
Use a DEBUG compiled version of the C-API of libmysql and code like following :
class CmysqlBlob
{
// Constructor / Destructor
CmysqlBlob();
virtual ~CmysqlBlob();
// Attributes
protected:
MYSQL* m_mysql;
BOOL m_bConnected;
// ...
};
CmysqlBlob::CmysqlBlob()
{
m_mysql = mysql_init(NULL);
m_bConnected = FALSE;
}
CmysqlBlob::~CmysqlBlob()
{
mysql_close(m_mysql);
m_mysql = NULL;
mysql_thread_end();
}
void main(void)
{
CmysqlBlob* mine = new CmysqlBlob();
delete mine;
}
Then see the debug-report...
Suggested fix:
Carefully find a 'free' or 'delete' for each call of a 'malloc' or 'new'.
It's because I'm not a MySQL developper, and not a C-developper, I can't figure out what's all created onto the heap/stack and whenever it's been released again.
Problem is, if the libmysql is created only once during the operation of a system, the lack of propper memory release isn't such a big problem. But if programs (like a provider or MyODBC, which do use libmysql.dll) are initialized often during a system's operation, you get more and more lost of available system recourses.
If you can find the time to fix this problem, I would be very gracefully ;-).
Description: There seems to be memory leaks, when using the "libmysql.dll" (C-API). They occure between the first call of 'mysql_init' and the 'mysql_close' - even when I enclose these commands between 'mysql_thread_start' and 'mysql_thread_end' I get even more memory leaks. I compiled the sources of libmysql into a DEBUG version, otherwise I didn't get them (the standard DLL delivered with a standard release of mysql is a RELEASE version, with that the debugger will not report any memory leaks). The leaks seems to exist, even without calling any other api-function (like a connect or a query). I'm developping a custom OLE-DB provider for MySQL to be used in VBA (I still have an "old fashioned" Access97, MyODBC doesn't always work - specially with BLOB's while they are written good via MyODBC but read incorrect - so that's why I wrote a fix via my custom provider). Following is a snippet of the debug-report from inside MS-VisualC++ : <...snip...> LDR: Automatic DLL Relocation in Msaccess.exe LDR: Dll LIBMYSQL.dll base 10000000 relocated due to collision with C:\Program Files\Logitech\MouseWare\System\LgWndHk.dll Loaded symbols for 'D:\Data\ActiveX\lkMySQL\Debug\libmysql.dll' Loaded 'C:\WINNT\system32\WSOCK32.DLL', no matching symbolic information found. Loaded 'C:\WINNT\system32\WS2_32.DLL', no matching symbolic information found. Loaded 'C:\WINNT\system32\WS2HELP.DLL', no matching symbolic information found. Loaded symbols for 'C:\WINNT\system32\MSVCRTD.DLL' Loaded symbols for 'C:\WINNT\system32\MFC42D.DLL' Loaded symbols for 'C:\WINNT\system32\MFCO42D.DLL' Loaded 'C:\WINNT\system32\RNR20.DLL', no matching symbolic information found. Loaded 'C:\WINNT\system32\RPCLTC1.DLL', no matching symbolic information found. The thread 0xB7 has exited with code 0 (0x0). The thread 0xB6 has exited with code 0 (0x0). The thread 0xB2 has exited with code 0 (0x0). The thread 0x5E has exited with code 0 (0x0). Info: AfxDllCanUnloadNow returning S_OK Info: AfxDllCanUnloadNow returning S_OK The thread 0xB0 has exited with code 0 (0x0). The thread 0x2D has exited with code 0 (0x0). Detected memory leaks! Dumping objects -> {78} normal block at 0x09381CF0, 92 bytes long. Data: < ˜ ¨É > 00 00 00 00 00 00 00 00 98 01 00 00 A8 C9 17 00 {48} normal block at 0x093722C0, 556 bytes long. Data: < È > 00 00 00 00 C8 00 00 00 00 00 00 00 00 00 00 00 Object dump complete. The thread 0xBA has exited with code 0 (0x0). The thread 0x9C has exited with code 0 (0x0). The thread 0xB5 has exited with code 0 (0x0). The thread 0x61 has exited with code 0 (0x0). The thread 0x52 has exited with code 0 (0x0). The program 'E:\Program Files\Microsoft Office\Office\Msaccess.exe' has exited with code 0 (0x0). How to repeat: Use a DEBUG compiled version of the C-API of libmysql and code like following : class CmysqlBlob { // Constructor / Destructor CmysqlBlob(); virtual ~CmysqlBlob(); // Attributes protected: MYSQL* m_mysql; BOOL m_bConnected; // ... }; CmysqlBlob::CmysqlBlob() { m_mysql = mysql_init(NULL); m_bConnected = FALSE; } CmysqlBlob::~CmysqlBlob() { mysql_close(m_mysql); m_mysql = NULL; mysql_thread_end(); } void main(void) { CmysqlBlob* mine = new CmysqlBlob(); delete mine; } Then see the debug-report... Suggested fix: Carefully find a 'free' or 'delete' for each call of a 'malloc' or 'new'. It's because I'm not a MySQL developper, and not a C-developper, I can't figure out what's all created onto the heap/stack and whenever it's been released again. Problem is, if the libmysql is created only once during the operation of a system, the lack of propper memory release isn't such a big problem. But if programs (like a provider or MyODBC, which do use libmysql.dll) are initialized often during a system's operation, you get more and more lost of available system recourses. If you can find the time to fix this problem, I would be very gracefully ;-).