RE: tk_mem.e bug
> -----Original Message-----
> From: Derek Parnell [mailto:ddparnell at bigpond.com]
> Matt,
> after doing some more testing of the tk_mem.e library, I must
> disagree with you. The lines you suggested to comment out are in fact
> needed. The reason is that when release_mem() is called with the parameter
being
> a 'memset' id rather than a memory address, it is assumed that the memset
> id was acquired by calling new_memset(). That routine creates a memset_id
by
> acquiring some memory from the heap and using that memory address as the
> memset id. Thus when releasing a memset, the id value must also be freed.
> That's what the lines in question are doing.
Hmmm, yes, now I can see that. However, I'm still getting the same results
with the new version. The only way [I've found] to get EuCOM to work is
without the line 'myFree(sets[1])'. For some reason, freeing the memset
owner's memory seems to be corrupting the heap. It's strange, because it
seems to happen only at after certain point, after a certain amount of
memory has been allocated. In the demo I had with EuCOM, it apparently
didn't use enough memory to cause the problem (unless you're using NT,
apparently).
I guess I'll just have to distribute a modified version of tk_mem.e and
accept a memory leak.
> However, in the version of tk_mem.e sent out with v0.55.1 of
> win32lib, there is a bug that may be relevent to the errors you are
having.
> If release_mem() is called using a memory address that is invalid or not
acquired using
> acquire_mem(), tk_mem.e still decrements the number of allocated blocks,
> even though the specified memory was not actually released. And when the
> block counter gets back to zero, it releases the heap. Thus any
subsequent
> references to previously acquired memory will cause a GPF. This bug has
been
> fixed in the next release.
No, that's not it. Trust me, I looked for that going on myself.
> There was another subtle bug that might have caused EuCOM to fail by not
> Win32lib apps. If the abort handler was not set up, the release_mem()
check
> for invalid memory addresses still tried to release the memory. This also
is
> fixed.
No, the failure was occuring during the call to HeapAlloc. The crash
happened somewhere within kernel32. I've tried using allocate and free, but
the results are even worse, for some reason.
Oh, well....
Matt Lewis
|
Not Categorized, Please Help
|
|
