MSComm produces memory leak
-
Hi y'all! I've got myself into a nasty situation again. I had to create a client and server application which would be put on different PC's and communicate using simple modems (analogue and ISDN). Not having a good component for serial communication and having to build a protocol of our own on top of it, I used the MSComm ActiveX object in Visual C++ 6 (with Win2K SDK) for talking with the modems on the COM ports. But when we started stress testing it, it turned out that the client suffered from a rather huge memory leak, and it wasn't in my code! (I'm sure of this, because a debug build doesn't dump any memory and the only thing that keeps on rising is the number of used CRT-blocks). The weird thing is that the server application uses the MSComm object almost in the same way and doesn't have this leak at all. When continually connecting and talking to each other the client application rises about 20 Kb each minute, so within an hour or 8 the Client PC will be swapping like crazy. The ONLY difference between the two programs is that the server application is the dialing party and the client application is the waiting party. :confused: :confused: :confused: :confused: Anyone ever had the same problem??? I think there must be some difference in the order of function calls. Could this really be of any difference??? Structured programming vs. chaotic mind boggling
-
Hi y'all! I've got myself into a nasty situation again. I had to create a client and server application which would be put on different PC's and communicate using simple modems (analogue and ISDN). Not having a good component for serial communication and having to build a protocol of our own on top of it, I used the MSComm ActiveX object in Visual C++ 6 (with Win2K SDK) for talking with the modems on the COM ports. But when we started stress testing it, it turned out that the client suffered from a rather huge memory leak, and it wasn't in my code! (I'm sure of this, because a debug build doesn't dump any memory and the only thing that keeps on rising is the number of used CRT-blocks). The weird thing is that the server application uses the MSComm object almost in the same way and doesn't have this leak at all. When continually connecting and talking to each other the client application rises about 20 Kb each minute, so within an hour or 8 the Client PC will be swapping like crazy. The ONLY difference between the two programs is that the server application is the dialing party and the client application is the waiting party. :confused: :confused: :confused: :confused: Anyone ever had the same problem??? I think there must be some difference in the order of function calls. Could this really be of any difference??? Structured programming vs. chaotic mind boggling
-
If you are using a VARIANT to read in data, are you clearing the variant when you are done with it? cve
I use COleVariants which should do the trick: // --- Code for reading --- COleVariant vInput = m_pMSCOMM->GetInput(); CString sBuffer = vInput.bstrVal; // --- Code for writing --- COleVariant vSend = sMessage; m_pMSCOMM->SetOutput( vSend ); Anyway, the same code is used for client and server and the server doesn't show ANY problems. If I use the VARIANTs in the wrong way, please tell me how to do it right. Structured programming vs. chaotic mind boggling
-
I use COleVariants which should do the trick: // --- Code for reading --- COleVariant vInput = m_pMSCOMM->GetInput(); CString sBuffer = vInput.bstrVal; // --- Code for writing --- COleVariant vSend = sMessage; m_pMSCOMM->SetOutput( vSend ); Anyway, the same code is used for client and server and the server doesn't show ANY problems. If I use the VARIANTs in the wrong way, please tell me how to do it right. Structured programming vs. chaotic mind boggling
Hello all!! I've figured out where my memory leak was! It was the way I took the variant out of the GetInput function. Since I've never really been a VB fan I never liked variants anyway, but now I'm truly scared of them ;) The code that I used was wrong: COleVariant var = MSComm1.GetInput(); This code leaves another copy of the variant hanging around inside the memory space of the MSComm object. If your client receives the content of several files, this means a lot of leaking memory. The solution is as follows: COleVariant var.Attach (MSComm1.GetInput()); This code explicitly tells the ActiveX component that we want to read the variant type and delete it from the COM-memory space... Have fun! Structured programming vs. chaotic mind boggling