login about faq

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.

asked Jul 20 '15 at 21:50

delphi777's gravatar image


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.


answered Jul 20 '15 at 23:01

jpbro's gravatar image

jpbro ♦

I did not set KeepEventLog to 1.. is it set by default? If not, then that is not my issue.



answered Jul 20 '15 at 23:13

delphi777's gravatar image


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.


answered Jul 21 '15 at 08:50

chilkat's gravatar image

chilkat ♦♦

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



answered Jul 21 '15 at 09:30

delphi777's gravatar image


Oh yeah and this is how I create the object when the thread is created: http://pastebin.com/mBp26twK


answered Jul 21 '15 at 09:40

delphi777's gravatar image


Thanks. I have a dozen or so emails to answer first, then I'll have a look. Please understand that this is not an official support channel. If my triage leads me to believe a very low probability of an actual memory leak, then I will not pursue it (because 98% of all claimed memory leaks turn out to be something else).

(Jul 21 '15 at 09:45) chilkat ♦♦

I know, I used the term memory leak because it is unexplained.. and creating and freeing the object after every quickGetStr solves it.. so it seems pretty blatant to me. Sorry for the trouble. I will be purchasing 2 licenses after this so don't think I'm some freeloader.

(Jul 21 '15 at 09:50) delphi777

Just to clarify.. 250 threads would get activated making about 250 calls to quickGetStr to load facebook.com(a page on there). This would result in memory shooting up to around 450mb, and it would remain there when done. When i created and freed the object in the doGet function.. after the 250 threads activated the memory was sitting at 27mb.. it hit only a max of 94mb when running.

(Jul 21 '15 at 09:55) delphi777

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..


answered Jul 21 '15 at 10:47

chilkat's gravatar image

chilkat ♦♦

That did not fix it.. I did the following: html := CkHttp__quickGetStr(Chilkat,pWideChar(widestring(URL))); //call close CkHttp_CloseAllConnections(Chilkat);

Memory does not clean up.. theres something else missing

(Jul 21 '15 at 14:00) delphi777
Your answer
toggle preview

Follow this question

By Email:

Once you sign in you will be able to subscribe for any updates here



Answers and Comments

Markdown Basics

  • *italic* or __italic__
  • **bold** or __bold__
  • link:[text](http://url.com/ "title")
  • image?![alt text](/path/img.jpg "title")
  • numbered list: 1. Foo 2. Bar
  • to add a line break simply add two spaces to where you would like the new line to be.
  • basic HTML tags are also supported



Asked: Jul 20 '15 at 21:50

Seen: 851 times

Last updated: Jul 21 '15 at 14:04

powered by OSQA