HeapFree problem

[jj2007]

I am running a testbed that
- creates a textfile with 500+ strings of randomised variable length, typically around 12k
- creates in parallel a file that stores the lengths only
- reads it back into a heapalloc'ed buffer, "tokenising" the strings to get their lengths (i.e. I put address and len in a separate 2*dword buffer)
- checks the correctness of the string lengths

All that runs fine but after, say, half a Million write/read loops I may get a HeapFree error (incorrect parameter). If I ignore that error, the prog continues successfully another half a Million times.

Once I got that HeapFree error directly after HeapValidate flagged a problem, but more often HeapValidate does not signal the problem - it's HeapFree that complains.

Around this rare event, the proggie slows down considerable but gains full speed soon after.

Any ideas how to interpret this behaviour, and how to deal with it?

Sorry for not posting the source but I think it is too complex for being useful here.

[sinsi]

One thing I noticed from HeapValidate was

Validating a heap may degrade performance, especially on symmetric multiprocessing (SMP) computers. The side effects may last until the process ends.

[hutch--]

JJ,

try it with GlobalAlloc() with the GMEM_FIXED flag.

[redskull]

Seperate threads, or just one?  Default process heap or new one from a HeapCreate() call?  I would start by using gflags to turn on "Enable heap validation on call", which will validate the whole thing, every time.  It will take forever to execute, but should quickly narrow it down.  Are you sure all the HeapAllocs are succeeding?

I'd like to see the behavior, if you can post the EXE to look at in Olly

-r

[jj2007]

red,

Thanks for the hint to gflags - never used before, it looks promising. But it seems I am close to the culprit already... will keep you posted :bg

[dedndave]

mightn't it be faster and cleaner to allocate 2 or 3 adequate blocks at the onset and re-use them ?
(as opposed to repeatedly allocating and freeing blocks)

[jj2007]

mightn't it be faster and cleaner to allocate 2 or 3 adequate blocks at the onset and re-use them ?
(as opposed to repeatedly allocating and freeing blocks)

I am actually improving the MasmBasic Recall algo:

Recall "\Masm32\include\Windows.inc", L$()
   MsgBox 0, L$(1000), "String 1000:", MB_OK

Size of files loaded may approach RAM limits, so it should be flexible...

[dedndave]

all i know is...
repeatedly allocating and freeing various sized blocks is going to trash the heap

[jj2007]

all i know is...
repeatedly allocating and freeing various sized blocks is going to trash the heap

It's going to fragment the heap, but under normal conditions it won't get corrupted. I have a little bug, that's all. Even with that bug, I do two Million 12k allocations and reallocations without getting a HeapAlloc error message. It crashes only in the rare event that I pass an invalid pointer to HeapFree.

Now I found a RamDisk that will serve to speed up the testing a little bit, and save my harddisk from nervous breakdown :bg

The bug is fixed, and right now I am in the stress test phase: the proggie writes and reads a randomised number of strings with a randomised length to the ramdisk. It seems to work, at least for the last few Gigabytes :bg