Archived Forum Post
Index of archived forum posts
Question:
Archived Forum PostQuestion:
I have been spent the past 4 hours trying to figure out where the memory is in my multi threaded application.
Thread creates the HCKHttp object, and then I have another function that calls quickGetStr as many times as I need for to navigate a website. (takes input for the URL).
However, every quickGetStr call the memory increases and does not free. The only way to fix this issue is to Create the HCKHttp and destroy it every time I call quickgetstr and then there is no memory leak.
Please tell me theres a function I can call after quickgetstr to free the memory? The problem with creating and destroying the HCKhttp object every time is that I lose the cookies in the memory, and I do not want to store them on the hard drive. I need the same hckhttp object globally for the thread so I can continue to do actions on the website.
Is the KeepEventLog property set to 1? If so, you should periodically call ClearBgEventLog to clear it. See:
KeepEventLog As Long
If 1, an in-memory event log is kept for any method that communicates with an HTTP server (such as Download, PostUrlEncoded, QuickGetStr, SynchronousRequest, etc.). When HTTP methods are called asynchronously, the event log can be checked while the HTTP operation is in in progress. This is done by examining the EventLogCount property and then fetching each event's name and value via the EventLogName and EventLogValue methods. See this example: Asynchronous HTTP.
The ClearBgEventLog method may be called to clear the in-memory event log.
I did not set KeepEventLog to 1.. is it set by default? If not, then that is not my issue.
thanks
If there is truly a memory leak, then it would be reproducible in the equivalent code (using Chilkat) in any programming language on any system. I'll explain why:
Chilkat is written in C++, and all builds for all programming languages and operating systems use the exact same underlying C++ Chilkat implementation. The only difference is the thin layer of code that sits atop this underlying core. This layer is not hand-written, but is generated. It is responsible for passing arguments into the underlying C++, and returning results back to the app. In the case of QuickGetStr, a string is passed in, and a string is returned. Now... if the memory leak is somehow within this thin outer-layer that is generated, then we should see the same memory leak across all Chilkat classes and methods that have string arguments, and/or return strings. This is not the case, otherwise everything would have the same memory leak -- so we can safely conclude that the thin outer-layer is not to blame.
Therefore, the memory leak (if one really exists) SHOULD be reproducible in any environment. If you provide a snippet of code in Delphi, I SHOULD be able to reproduce the exact same behavior in C++ -- where memory leaks can be detected with great precision. I suspect there is no actual memory leak, and here are the reasons why:
1) The HTTP object keeps a pool of open connections. If an app fetches a URL from website A, and then B, and then C, and then repeats the same with A, B, and C. Then the connections for A, B, and C, may have stayed resident and open within the HTTP object (assuming the response did not have a Connection:close header). This might appear as a memory leak -- but it is not. The subsequent requests can re-use the same connection. One way to discern the problem is to test with 100's of requests vs. a handful. If memory stops growing at a certain point, then it's likely not a leak.
2) In Chilkat's normal day-to-day operations, everything that is ever done -- during development, during QA, etc. involves the automatic checking for memory leaks. It's just part of the process. Coding standards within Chilkat are very strict. As a result, memory leaks are very rare.
3) What jpbro said earlier is true -- there are internal logs that could possibly grow.
If you are certain there is a memory leak, then please provide the simplest snippet of code that demonstrates how to reproduce the problem. I'm not claiming it's impossible that a memory leak does not exist, but only that it is unlikely.
Oh trust me, I completely understand where your coming from, however there is something wrong. I'm thinking something is being stored after every quickGetStr which is causing the memory to get out of control. I've tested this for hours.. commenting out code trying to pin point the issue. Only thing that fixed this was Creating and destroying the HCKhttp object in the doGet function itself (The function below has the memory issue, i removed the creating and destroying to show you how I had it, and how i need it, the chilkat HCKhttp object is created when the thread is created):
I put up a pastebin because the code pasted in here was a mess. http://pastebin.com/qrpeAKqh
Thanks
Oh yeah and this is how I create the object when the thread is created: http://pastebin.com/mBp26twK
Thanks! After thinking a bit more, a memory leak is a case where allocated memory exists, but nothing points to it anymore. It's been lost track of. In this case, it hasn't been lost track of -- because if the object is destructed the memory is cleaned up.
Therefore, I think the issue is as I described in case #1 above. Try this: Instead of destroying the HCKhttp object each time, call the CkHttp_CloseAllConnections function. I suspect the kept-open connections are what's accumulating..