memory leak with wxSocket

If you are using the main C++ distribution of wxWidgets, Feel free to ask any question related to wxWidgets development here. This means questions regarding to C++ and wxWidgets, not compile problems.
Post Reply
tsu
In need of some credit
In need of some credit
Posts: 2
Joined: Tue Apr 07, 2009 4:06 pm

memory leak with wxSocket

Post by tsu » Wed Apr 08, 2009 10:54 am

Dear wx users !

After tens of years of not updating my programming know-how I only lately started to update it towards C++, GUI-programming under MS Windows, using MS Visual Studio and looking at libraries/frameworks like e. g. FLTK, GTK, MathGL, Grace, OpenCV, Qt, SDL and wxWidgets and wxMathPlot.

I want to build a small program that plots sets of signals resp. vector data on the screen which it receives via TCP/IP or better UDP messages and which performs most possibly fast ("real-time"). It could probably be done quite easily with C# and the .NET features but I doubt that this would satisfy me regarding the "performance-to-PC-capability-ratio".

So currently I think wxWidgets and wxMathPlot are a very good choice for me !

Enough background - here is my issue:

For my program I use parts of the examples:
wxWidgets-2.8.9\samples\sockets\client.cpp
wxWidgets-2.8.9\samples\sockets\server.cpp

Even when I test these two example programs unmodified, I get memory leak warnings from my Visual Studio Express C++ debugger under certain conditions:

start server with debugger
start client without debugger
open TCP/IP connection from client (menu SocketClient - Open session)
exit server
Visual Studio reports in the debugger output:
"server.exe": "E:\wx\samples\sockets\vc_mswd\server.exe" geladen, Symbole wurden geladen.
"server.exe": "C:\WINDOWS\system32\ntdll.dll" wurde geladen
"server.exe": "C:\WINDOWS\system32\kernel32.dll" wurde geladen
"server.exe": "C:\WINDOWS\WinSxS\x86_Microsoft.Windows.Common-Controls_6595b64144ccf1df_6.0.2600.2982_x-ww_ac3f9c03\comctl32.dll" wurde geladen
"server.exe": "C:\WINDOWS\system32\msvcrt.dll" wurde geladen
"server.exe": "C:\WINDOWS\system32\advapi32.dll" wurde geladen
"server.exe": "C:\WINDOWS\system32\rpcrt4.dll" wurde geladen
"server.exe": "C:\WINDOWS\system32\secur32.dll" wurde geladen
"server.exe": "C:\WINDOWS\system32\gdi32.dll" wurde geladen
"server.exe": "C:\WINDOWS\system32\user32.dll" wurde geladen
"server.exe": "C:\WINDOWS\system32\shlwapi.dll" wurde geladen
"server.exe": "C:\WINDOWS\system32\wsock32.dll" wurde geladen
"server.exe": "C:\WINDOWS\system32\ws2_32.dll" wurde geladen
"server.exe": "C:\WINDOWS\system32\ws2help.dll" wurde geladen
"server.exe": "C:\WINDOWS\system32\comdlg32.dll" wurde geladen
"server.exe": "C:\WINDOWS\system32\shell32.dll" wurde geladen
"server.exe": "C:\WINDOWS\system32\ole32.dll" wurde geladen
"server.exe": "C:\WINDOWS\system32\oleaut32.dll" wurde geladen
"server.exe": "C:\WINDOWS\WinSxS\x86_Microsoft.VC90.DebugCRT_1fc8b3b9a1e18e3b_9.0.21022.8_x-ww_597c3456\msvcr90d.dll" wurde geladen
"server.exe": "C:\WINDOWS\system32\uxtheme.dll" wurde geladen
"server.exe": "C:\WINDOWS\system32\mswsock.dll" wurde geladen
"server.exe": "C:\WINDOWS\system32\hnetcfg.dll" wurde geladen
"server.exe": "C:\WINDOWS\system32\wshtcpip.dll" wurde geladen
"server.exe": "C:\WINDOWS\system32\wshtcpip.dll" entladen.
Der Thread 'Win32 Thread' (0x99c) hat mit Code 0 (0x0) geendet.
"server.exe": "C:\WINDOWS\system32\hnetcfg.dll" entladen.
Detected memory leaks!
Dumping objects ->
{1799} normal block at 0x00BB3950, 16 bytes long.
Data: < r > 02 00 07 72 7F 00 00 01 00 00 00 00 00 00 00 00
{1798} normal block at 0x00BB3900, 20 bytes long.
Data: <P9 > 50 39 BB 00 10 00 00 00 01 00 00 00 02 00 00 00
{1797} normal block at 0x00BB3878, 76 bytes long.
Data: < X 9 > 01 CD CD CD 58 0F 00 00 00 00 00 00 00 39 BB 00
{1796} normal block at 0x00BB3690, 20 bytes long.
Data: < > 00 00 00 00 00 00 00 00 00 00 00 00 CD CD CD CD
{1795} normal block at 0x00BB37C0, 120 bytes long.
Data: < Ub x8 > 00 55 62 00 00 00 00 00 78 38 BB 00 03 00 00 00
Object dump complete.
Das Programm "[0x6A8] server.exe: Systemeigen" wurde mit Code 0 (0x0) beendet.

If the TCP connection is closed before exiting, then no memory leaks are reported.
So it seems that when exiting the server with an open TCP connection, some socket objects are not properly deleted before the program ends.
I tried

m_server->Shutdown();
m_server->Destroy();

in the MyFrame::OnQuit method to shutdown or destroy the wxSocketServer object in case, but this results in an exeption when exiting the server via menu-File-Exit or in the same memory leak error report when exiting the server via the top right window button.

Is there a way to only shutdown or destroy the socket objects which are eventually still open and bound to a wxSocketServer object ?
Would this solve the problem I described ?
Or is the problem I described even a bug within the wx socket functions ?

Many thanks in advance for your help or advice.

Best regards
tsu

spectrum
Filthy Rich wx Solver
Filthy Rich wx Solver
Posts: 207
Joined: Sat Jul 21, 2007 12:17 pm

Post by spectrum » Thu Apr 09, 2009 10:33 am

hi tsu,

often, so small memory leaks are bugs of the windows dll functions. At the end, wxWidgets use the OS API'es. Please check using some program as Rational Purify, or others, the exact function/module that cause the leak.

greetings,
Angelo
spectrum

tsu
In need of some credit
In need of some credit
Posts: 2
Joined: Tue Apr 07, 2009 4:06 pm

Post by tsu » Wed Apr 15, 2009 9:35 am

Hi spectrum !

Many thanks for your reply.

I understand from you ("so small memory leaks...") that the memory leaks I have observed are not so critical.

Further analysis as you proposed with a special tool seems to be for me at the moment to difficult (I have no such tool, nor the experience) and not so important.

Instead, I tried to find out whether your assumption that the origin of the defect is somewhere in the windows API is true. I found that in src/msw/gsocket.cpp the Winsock functions WSAStartup and WSACleanup are indeed called when the samples\sockets\server.cpp program starts and ends. I assume that WSACleanup should indeed cleanup every possibly still open socket object and respective memory and that it probably fails to do so in this case.

So, I am satisfied with the answer ... at least for the moment ... though ... it might be interesting to know whether the defect also occurs when the test I have described is done under another OS.

Best regards
Thomas

Post Reply