On Mon, 23 Feb 2009, Pritpal Bedi wrote:

Hi,

> Harbour compiled with -DHB_FM_WIN_ALLOC 
> doe snot produce any unreleased Virtual Mem Pages 
> as reported by MemProof.

So we can try pacify it.
But I'm interesting why Toninho didn't confirm your results.
Is it newer BCC problem or wrongly created Harbour binaries
or test application.

> Plus exiting a thread also releases the memory properly.

AFAIK there was no bug in thread memory and DLMALLOC at all.

> With dlmalloc.c, a thread was never releasing the memory.

It's not true because dlmalloc code used by Harbour does not
use and thread local memory or storage. All threads use exactly
the same memory poll.

> You start another thread, keep on initiating other threads,
> close those modules, Task Manager going on reporting 
> increase in memory. At the appln exit, unfreed virual blocks
> keep on increasing by the number of threads an appln 
> fires.

I'm sorry Pritpal but I do not believe that you made such
full tests. Technically it's impossible what you described
until VirtualAlloc()/VirtualFree()/VirtualQuery() does
not make sth different then MS describes. Though it possible
that the testing tool wrappers intorduced some differences.

> This also shed light on uhttpd's reported high 
> memory consumption in another thread. Francesco ?

I do not think so.

> Something very serious if dlmalloc is the default for Harbour.
> Probably easy to fix if someone concentrates onto that.

The only one thing which probably exist in DLMALLOC which
it not pleasure but does not cause any real problems is
the fact that it may not release all memory area allocated
by VirtualAlloc() and always keeps some small block(s) for
performance reasons - DLMALLOC does not know that the
application is exiting so it will not allocate any new
memory block in a while. So keep some peace of memory
to quickly realize such request. It's nothing wrong in
the above though it may cause some false alarms in tools
like memproof so if it will not cost too much we can try
to pacify it.

best regards,
Przemek
_______________________________________________
Harbour mailing list
[email protected]
http://lists.harbour-project.org/mailman/listinfo/harbour

Reply via email to