0

Our application has a feature to actively connect to the customers' internal factory network and send a message when inspection events occur. The customer enters the IP address and port number of their machine and application into our software.

I'm using a TClientSocket in blocking mode and have provided callback functions for the OnConnect and OnError events. Assuming the abovementioned feature has been activated, when the application starts I call the following code in a separate thread:

// Attempt active connection
try
    m_socketClient.Active := True;
except
end;

// Later...
// If `OnConnect` and socket is connected...send some data!
// If `OnError`...call `m_socketClient.Active := True;` again

When IP + port are valid, the feature works well. But if not, after several thousand errors (and many hours or even days) eventually Windows socket error 10055 (WSAENOBUFS) occurs and the application crashes.

Various articles such as this one from ServerFramework and this one from Microsoft talk about exhausting the Windows non-paged pool and mention (1) actively managing the number outstanding asynchronous send operations and (2) releasing the data buffers that were used for the I/O operations.

My question is how to achieve this and is three-fold:

A) Am I doing something wrong that memory is being leaked? For example, is there some missing cleanup code in the OnError handler?

B) How do you monitor I/O buffers to see if they are being exhausted? I've used Process Explorer to confirm my application is the cause of the leak, but ideally I'd need some programmatic way of measuring this.

C) Apart from restarting the application, is there a way to ask Windows to clear out or release I/O operation data buffers?

Code samples in Delphi, C/C++, C# fine.

AlainD
  • 5,413
  • 6
  • 45
  • 99
  • You probably know that `TClientSocket` has been deprecated since Delphi 6 which is now sixteen and half a year ago. I'd not be surprised if those components don't clean up handles properly. Other Delphi components that were very poorly written (like the shell components) had also been deprecated and were removed later. – Günther the Beautiful Nov 07 '17 at 16:08
  • Thanks Günther, actually I didn't know that. Need to refresh the components I use! After a day of research and testing I think I've discovered the problem (which reflects my inexperience in using these TCP/IP components)...when the socket times out and fires off the `OnError` event, you're supposed to call `m_socketClient.Socket.Close()`. Am busy completing my investigations and will knock up an answer based on that. – AlainD Nov 07 '17 at 20:01
  • `TClientSocket` may be deprecated, but it is a fairly rock-solid component. I've never had any memory/resource issues with it, and I've used it for a very long time. But I've never tried setting `Active := True` in the `OnError` event. I always `Close()` the failed socket in that event, and then let the thread decide when to open the socket again. If an error occurs when opening a connection, it is best to wait a few seconds before trying to open the connection again. If an error occurs during reading/writing I/O, then re-connect right away. – Remy Lebeau Nov 07 '17 at 20:57
  • Thanks Remy. Agree, `TClientSocket` is excellent...I just neglected to call `Close()` on the socket after an error. Do you have to call `Close()` every time you stop using the socket (such as when the server disconnects)? I'm sure the Embarcadero documentation states this all clearly somewhere, but I didn't spot it. We didn't spot this but in development because its an advanced feature generally tested on a connected system (or only for a few hours on a non-connected system). Shame to discover at the customer...but at least I'm ready to release a fix :o) – AlainD Nov 07 '17 at 21:48

1 Answers1

0

A) The cause of the resource leak was a programming error. When the OnError event occurs, Socket.Close() should be called to release low-level resources associated with the socket.

B) The memory leak does not show up in the standard Working Set memory use of the process. Open handles belonging to your process need to be monitored which is possible with GetProcessHandleCount. See this answer in Delphi which was tested and works well. This answer in C++ was not tested but the answer is accepted so should work. Of course, you should be able to use GetProcessHandleCount directly in C++.

C) After much research, I must conclude that just like a normal memory leak, you cannot just ask Windows to "clean up" after you! The handle resource has been leaked by your application and you must find and fix the cause (see A and B above).

AlainD
  • 5,413
  • 6
  • 45
  • 99