>xHarbour does not enable DLMALLOC with the same conditions as
>Harbour and it's the reason of difference. I guess you are using
>__EXPORT__ macro which effectively disables DLMALLOC in xHarbour.
>
>BTW if you can test the above code with BCC6.1 to confirm the results
>then it will really help.
Przemek
Przemyslaw Czerpak-2 wrote:
>
>> For ciriticalSection unreleased handles, it is the same with
>> -DHB_FM_WIN_ALLOC an -DHB_FM_DL_ALLOC. The difference
>
> I know. I removed critical section deallocations due to problems
> with VISTA and additional cost which we will have to pay for s
On Tue, 24 Feb 2009, Pritpal Bedi wrote:
Hi Pritpal,
> For ciriticalSection unreleased handles, it is the same with
> -DHB_FM_WIN_ALLOC an -DHB_FM_DL_ALLOC. The difference
I know. I removed critical section deallocations due to problems
with VISTA and additional cost which we will have to pay f
On Wed, 25 Feb 2009, Andi Jahja wrote:
> It's Harbour problem, IMHO. Have you try with xHarbour and see how
> memproof reporting errors? In my case, Harbour did not release Virtual
> Memory, but xHarbour released it. So, it is not Borland problem ;-)
Yes and Harbour virtually effects this C code:
On Tue, 24 Feb 2009 13:17:59 -0300
"toni...@fwi" wrote:
> Hi Przemek,
>
> >Because it's part of CRTL.
> >C compiler still have to allocate the console so ask borland
> >why it does not deallocate it.
> Thanks, now I understand.
>
> >And what are the results for above code if you compile it usin
Hello Przemek
Przemyslaw Czerpak-2 wrote:
>
> So if you want then I add such functionality but it will be
> enabled only when USE_DL_PREFIX is defined. If you make some
> test which confirm that the virtual addresses as freed as
> expected then we can enable USE_DL_PREFIX as default.
>
I wil
Hi Przemek,
>Because it's part of CRTL.
>C compiler still have to allocate the console so ask borland
>why it does not deallocate it.
Thanks, now I understand.
>And what are the results for above code if you compile it using hbmk2?
The same, of course the problem is with BCC 6.10
Thank you to ex
On Tue, 24 Feb 2009, toni...@fwi wrote:
Hi,
> Thanks for answer.
> >So why Pritpal has different results?
> >Can you agree them ;-)
> I agree of course and I don't know, but I compiled harbour with
> DL_ALLOC and the results change in VirtualAlloc, but the rest are the
> same. Why CreateFile, Get
Hi Przemek,
Thanks for answer.
>So why Pritpal has different results?
>Can you agree them ;-)
I agree of course and I don't know, but I compiled harbour with
DL_ALLOC and the results change in VirtualAlloc, but the rest are the
same. Why CreateFile, GetStdHandle and InitializeCriticalSection
rema
On Tue, 24 Feb 2009, toni...@fwi wrote:
Hi,
> I recompile my local Harbour to use -DHB_FM_WIN_ALLOC and the result
> are the same as using -DHB_FM_STD_ALLOC in my previous mail.
So why Pritpal has different results?
Can you agree them ;-)
It's possible that you are linking some external librari
Hi Przemek,
I recompile my local Harbour to use -DHB_FM_WIN_ALLOC and the result
are the same as using -DHB_FM_STD_ALLOC in my previous mail.
Thank you.
Regards,
Toninho.
__
Faça ligações para outros computadores com o novo Yahoo! Messenger
http:
On Tue, 24 Feb 2009, toni...@fwi wrote:
> My environment is: Windows Vista Home Premium and set
> HB_ARCHITECTURE=win, set HB_COMPILER=bcc32
> My Harbour is compiled with:
> SET HB_USER_CFLAGS=-DHB_GUI -DHB_FM_STATISTICS_OFF -DHB_NO_PROFILER
> -DADS_LIB_VERSION=700 -DHB_HASH_MSG_ITEMS -DHB_NO_DEBUG
>But I'm interesting why Toninho didn't confirm your results.
>Is it newer BCC problem or wrongly created Harbour binaries
>or test application.
Hi Przemek,
A simple test:
---cut---
procedure main()
? "hello word"
return
---cut---
produces:
---cut---
1 File 001
On Tue, 24 Feb 2009, Przemyslaw Czerpak wrote:
Hi,
> 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
> perfo
Pritpal,
no, uhttpd leaks memory on OS/2 also where dlmalloc is not available.
Maurilio.
Pritpal Bedi wrote:
> Hello Przemek
>
> Harbour compiled with -DHB_FM_WIN_ALLOC
> doe snot produce any unreleased Virtual Mem Pages
> as reported by MemProof.
>
> Plus exiting a thread also releases the
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
Hi
I retreat my findings.
Dlmalloc.c does not increase the size of the memory
but memProof.exe reports unfreed blocks for sure.
-WIN_ALLOC does not report any unfree blocks.
Regards
Pritpal Bedi
Francesco Saverio Giudice wrote:
>
> Hi Pritpal,
> at first look it seems that with -DHB_FM_WIN
Hi Pritpal,
at first look it seems that with -DHB_FM_WIN_ALLOC is better, but the
problem is still there.
I've only a doubt: do I set correctly my env ? I have added:
set HB_USER_CFLAGS=-DHB_LEGACY_OFF -DHB_FM_STATISTICS_OFF -DHB_FM_WIN_ALLOC
I think yes.
So I have to continue to investigate.
Hi Pritpal,
Il 23/02/2009 20.45, Pritpal Bedi ha scritto:
This also shed light on uhttpd's reported high
memory consumption in another thread. Francesco ?
Just testing
Best regards
Francesco
___
Harbour mailing list
Harbour@harbour-project.org
http
19 matches
Mail list logo
