Codejock Developer Community : Severe Memory Leak http://forum.codejock.com/ Copyright (c) 2006-2013 Web Wiz Forums - All Rights Reserved. Fri, 15 May 2026 11:57:50 +0000 Mon, 15 Jun 2009 16:23:42 +0000 http://blogs.law.harvard.edu/tech/rss Web Wiz Forums 12.04 360 forum.codejock.com/RSS_post_feed.asp?TID=7921 <![CDATA[Codejock Developer Community]]> http://forum.codejock.com/forum_images/codejock-logo.gif http://forum.codejock.com/ <![CDATA[Severe Memory Leak : I had a confirmation from already...]]> http://forum.codejock.com/forum_posts.asp?TID=7921&PID=49963&title=severe-memory-leak#49963 Author: mdoubson
Subject: 7921
Posted: 15 June 2009 at 4:23pm

I had a confirmation from already closed Issue:
Hi, No more leaks in 13.1 Beta. Thanks!
But: Is it my feeling that the Report still uses quite a bit of memory (1Kb per row)
]]> Mon, 15 Jun 2009 16:23:42 +0000 http://forum.codejock.com/forum_posts.asp?TID=7921&PID=49963&title=severe-memory-leak#49963 <![CDATA[Severe Memory Leak : sserge wrote:The problem...]]> http://forum.codejock.com/forum_posts.asp?TID=7921&PID=26267&title=severe-memory-leak#26267 Author: ABuenger
Subject: 7921
Posted: 21 September 2007 at 6:22am

Originally posted by sserge sserge wrote:

The problem is related to MFC 6.0 CString implementation. CString objects have internal cache and do not deallocate memory when string is destroyed. Their memory is kept in the cache and reused in the feature string allocations. (This was useful in the old windows versions)

This is not a leak, just such behavior.


CString in MFC 6.0 uses CFixedAlloc for memory allocation which, as Serge said, keeps a list of all allocated memory for reusage in the release build. So it's actually not a leak but a feature.

]]> Fri, 21 Sep 2007 06:22:00 +0000 http://forum.codejock.com/forum_posts.asp?TID=7921&PID=26267&title=severe-memory-leak#26267 <![CDATA[Severe Memory Leak : Some more information: Report...]]> http://forum.codejock.com/forum_posts.asp?TID=7921&PID=26205&title=severe-memory-leak#26205 Author: sserge
Subject: 7921
Posted: 20 September 2007 at 5:43pm

Some more information:

Report control has 2 features to optimize memory usage.
This is useful for big amount of records (more than 10 000).

Let me note that features described below has real effect in Release build only.
In Debug build, program which used these features may work even slower than without them.

1. Custom Heap.
Some Report Control classes, which represent data (records, record items and rows),
has overridden new/delete operators which use own Allocator object to allocate/deallocate
memory on object create.
The allocator has 2 modes:
  1. Standard (by default) - the default application heap is used, as for any other Objects.
  2. CustomHeap      - the separate custom heap is used by this allocator.
                      (See HeapCreate and other related Windows API functions)

Allocator manage custom heap internally.
When all objects deleted - allocator destroy heap (and create again for next allocations).
This "Really" free all memory after all data removed and avoid Heap fragmentation problem.

Also by default Allocator enable "Low-fragmentation Heap" (LFH) feature for custom heap.
This optimize heap work in WinXP and later. But it does not works under debugger.

2. Batch Allocation.
If we need to allocate many objects of the same type (size) it is more effective
to allocate memory not for each object separately, but for some amount of such objects at one time (by batch).

Batch Allocation implemented over Custom heap.
This means that it can alloc batches in the standard heap as far as in the custom heap.

When you call "new" for some batch allocable class,
Batch Allocation mechanism allocate block for 1024 objects in the heap,
return pointer for one object and add other 1023 to "Free List".
For feature allocations objects from this "Free List" will be returned instead of new allocation in the heap.
When free list will be empty - new batch block will be allocated and added to "Free List".

Whensuch object deleted (operator delete called) - it is added to "FreeList" too (and will be used again for future allocations).

This is increase allocation/deallocation speed and allow to avoid heap fragmentation.

Batch Allocation manage list of batch blocks and list of free objects in each block.
When all objects from some batch block is in free list - such block deleted automatically.
FreeExtraData() method allow to delete these batch blocks from memory (from heap).

This means that you have to call FreeExtraData after Remove All records and rows to really free memory.
But if you plan to add some data again you should not do this.
In this case you may call FreeExtraData after add new records and populate.

--
WBR,
Serge
]]> Thu, 20 Sep 2007 17:43:21 +0000 http://forum.codejock.com/forum_posts.asp?TID=7921&PID=26205&title=severe-memory-leak#26205 <![CDATA[Severe Memory Leak : Copying there an answer to this...]]> http://forum.codejock.com/forum_posts.asp?TID=7921&PID=26204&title=severe-memory-leak#26204 Author: sserge
Subject: 7921
Posted: 20 September 2007 at 5:42pm

Copying there an answer to this question from support area:

The problem is related to MFC 6.0 CString implementation. CString objects have internal cache and do not deallocate memory when string is destroyed. Their memory is kept in the cache and reused in the feature string allocations. (This was useful in the old windows versions)

This is not a leak, just such behavior.

You can click Fill and Clear many times and see that used memory will not grow and grow as for the leak.

I see only one way to fix this - use MFC 8.0 OCX build. MFC 8.0 CString implementation has no such cache.


Also to optimize memory usage you can enable the following features:

Private Sub Form_Initialize()
  ReportControlGlobalSettings.UseReportCustomHeap
  ReportControlGlobalSettings.UseBatchAllocation  
End Sub


Also you may use
  ReportControlGlobalSettings.FreeBatchExtraData
after remove all data to free cached memory.

--
WBR,
Serge
]]> Thu, 20 Sep 2007 17:42:34 +0000 http://forum.codejock.com/forum_posts.asp?TID=7921&PID=26204&title=severe-memory-leak#26204 <![CDATA[Severe Memory Leak : ... any idea CJ team ? ]]> http://forum.codejock.com/forum_posts.asp?TID=7921&PID=26027&title=severe-memory-leak#26027 Author: mav46
Subject: 7921
Posted: 17 September 2007 at 10:54am

... any idea CJ team ?]]> Mon, 17 Sep 2007 10:54:00 +0000 http://forum.codejock.com/forum_posts.asp?TID=7921&PID=26027&title=severe-memory-leak#26027 <![CDATA[Severe Memory Leak : yes, it&#039;s true. I&#039;have...]]> http://forum.codejock.com/forum_posts.asp?TID=7921&PID=25634&title=severe-memory-leak#25634 Author: mav46
Subject: 7921
Posted: 07 September 2007 at 10:05am

yes, it's true. I'have realize it on one of my projects. I have the same memory leak when I populate the report control with a custom caption on all the filed of the report .....
 
There is a urgent need to solve this bug, please.
 
 
]]> Fri, 07 Sep 2007 10:05:38 +0000 http://forum.codejock.com/forum_posts.asp?TID=7921&PID=25634&title=severe-memory-leak#25634 <![CDATA[Severe Memory Leak : Is there any response on this?...]]> http://forum.codejock.com/forum_posts.asp?TID=7921&PID=25543&title=severe-memory-leak#25543 Author: dhugal
Subject: 7921
Posted: 04 September 2007 at 12:31pm

 
Is there any response on this?
 
I have made a support request - no response.
I have tried phoning you guys on the international number all afternoon - no answer (12 noon EST).
 
Please help me!
]]> Tue, 04 Sep 2007 12:31:53 +0000 http://forum.codejock.com/forum_posts.asp?TID=7921&PID=25543&title=severe-memory-leak#25543 <![CDATA[Severe Memory Leak : We have been using the Code Jock...]]> http://forum.codejock.com/forum_posts.asp?TID=7921&PID=25475&title=severe-memory-leak#25475 Author: dhugal
Subject: 7921
Posted: 03 September 2007 at 3:20am

We have been using the Code Jock controls for some time but just recently our application seems to be using a lot lot more ram. I did some investigation and it appears that when we use the Report Grid control and add a lot of items where we set the caption to be different from the value (we do this for all numeric & date fields because we format them nicely for the user) the grid exhibits a severe memory leak.

I have put together an example project demonstrating this:

uploads/20070903_032029_ReportControlMe.zip
 
If you fill the grid with 20,000 rows each the control consumes a fair amount of ram as expected - when you then clear it all of that ram is freed (correction - most). If however you fill it with the same number of rows and explicitely set the caption on each of the values the grid consumes a lot of ram again but when you clear it is not all freed - in fact a large percent is never freed. When I am running this in a VB6 IDE the ram isn't even freed when I close the application and I have to terminate the IDE to free it.

The memory figures (KB) with 20,000 records / 40 Columns are as follows:

Project started in IDE and form displayed: 14,920
Grid filled with rows but Caption not set: 198,824
Grid then cleared: 17,272
(A slight gain that needs to be checked we have lost 3 meg somewhere)
Grid then filled with rows and Caption set explicitely: 261,868
Grid then cleared: 129,352
(We have lost over 100 meg of ram somewhere!)


App closed return to VB design environmentGrid then cleared: 129,380
(We have still not reclaimed the missing 100 meg!)

This is obviously very urgent for us as we are using this with a very high number of users in a Terminal Services environment so any memory leaks result in degredation of the server performance and eventual crashes in our application.

Can you give me an estimate for a fix please?

Dhugal.

]]> Mon, 03 Sep 2007 03:20:54 +0000 http://forum.codejock.com/forum_posts.asp?TID=7921&PID=25475&title=severe-memory-leak#25475