>> The only "problem" with valgrind is that it doesn't work
>> on Windows, and most QT developers use Windows. Otherwise
>> it's indeed the best tool.
>
> And seems that such port is not even planed.
Yes, I've read some text about this, it'd be too much
work.
> In BCC there is CodeGuard tool
On Mon, 04 Jan 2010, Szak�ts Viktor wrote:
Hi,
> The only "problem" with valgrind is that it doesn't work
> on Windows, and most QT developers use Windows. Otherwise
> it's indeed the best tool.
And seems that such port is not even planed.
In BCC there is CodeGuard tool which you can also try
>> We're lured into the impression that HBQT doesn't leak memory.
>> I say this because HBQT in dynamic mode doesn't seem to be
>> using our memory allocation functions at all, so nothing is
>> tracked, which means we're getting a constant zero leak
>> whatever is happening inside HBQT.
>> Do yo
On Mon, 04 Jan 2010, Szak�ts Viktor wrote:
Hi,
> We're lured into the impression that HBQT doesn't leak memory.
> I say this because HBQT in dynamic mode doesn't seem to be
> using our memory allocation functions at all, so nothing is
> tracked, which means we're getting a constant zero leak
>
>-Original Message-
>From: Przemysław Czerpak [mailto:dru...@acn.waw.pl]
>Sent: Monday, January 04, 2010 2:51 PM
>To: Harbour Project Main Developer List.
>Subject: Re: [Harbour] SF.net SVN: harbour-project:[13444]
>trunk/harbour
...
>memory was allocated and rele
> On Mon, 04 Jan 2010, Bisz István wrote:
>> OK. Maybe I was too happy to see this message, sorry.
>
> Ups. I've just seen that it was not always shown but only
> when //INFO were used so it's fine for me. I only suggest
> to replace:
> hb_snprintf( buffer, sizeof( buffer ),
>HB_
On Mon, 04 Jan 2010, Bisz István wrote:
> An another issue is I think is in hbtrace.c with the following line:
> MultiByteToWideChar( CP_ACP, 0, hb_strncpy( message, buf.psz,
> sizeof( message ) - 1 ), -1,
> buf.lp, HB_SIZEOFARRAY( buf.lp ) );
> The strncpy(
: Harbour Project Main Developer List.
Subject: Re: RE: RE: [Harbour] SF.net SVN: harbour-project:[13444] trunk/harbour
On Mon, 04 Jan 2010, Bisz István wrote:
> OK. Maybe I was too happy to see this message, sorry.
Ups. I've just seen that it was not always shown but only
when //INFO were
On Mon, 04 Jan 2010, Bisz István wrote:
> OK. Maybe I was too happy to see this message, sorry.
Ups. I've just seen that it was not always shown but only
when //INFO were used so it's fine for me. I only suggest
to replace:
hb_snprintf( buffer, sizeof( buffer ),
HB_I_("Memory al
] SF.net SVN: harbour-project:[13444] trunk/harbour
On Mon, 04 Jan 2010, Bisz István wrote:
Hi,
> First of all Happy New Year!
Thank you and Happy New Year.
> The intention behind of this message, is to inform the developer that
> everything goes well: the FM statistic module col
On Mon, 04 Jan 2010, Bisz István wrote:
Hi,
> First of all Happy New Year!
Thank you and Happy New Year.
> The intention behind of this message, is to inform the developer that
> everything goes well: the FM statistic module collects the necessary
> info and the analysis at the end of the progr
>>> If this is the only reason then we should revert this modification.
>>> For such functionality we have //info switch which can be used to
>>> verify if FM statistic module is enabled and how much memory was
>>> allocated and released. Just simply run any applications with this
>>> switch, i.e.:
Czerpak
Sent: 2010. január 4. 16:06
To: Harbour Project Main Developer List.
Subject: Re: [Harbour] SF.net SVN: harbour-project:[13444] trunk/harbour
On Mon, 04 Jan 2010, Szak�ts Viktor wrote:
Hi,
> > If this is the only reason then we should revert this modification.
> > For such func
On Mon, 04 Jan 2010, Szak�ts Viktor wrote:
Hi,
> > If this is the only reason then we should revert this modification.
> > For such functionality we have //info switch which can be used to
> > verify if FM statistic module is enabled and how much memory was
> > allocated and released. Just simply
>> In fact the whole point of previous implementation was
>> that we warn developers if there _is_ a leak, and stay
>> silent if there isn't. This way it's apparent when there
>> is a problem and when not. If we wash together the
>> two messages, it will be less easy to spot if there is
>> a pr
On Sun, 03 Jan 2010, Szak�ts Viktor wrote:
Hi,
> In fact the whole point of previous implementation was
> that we warn developers if there _is_ a leak, and stay
> silent if there isn't. This way it's apparent when there
> is a problem and when not. If we wash together the
> two messages, it wi
István
Sent: 2010. január 3. 1:00
To: 'Harbour Project Main Developer List.'
Subject: RE: [Harbour] SF.net SVN: harbour-project:[13444] trunk/harbour
>What is the way to force our allocation functions to be
>used by QT C++ new/delete operators?
>Without this, any fm.c
>What is the way to force our allocation functions to be
>used by QT C++ new/delete operators?
>Without this, any fm.c leak measurement is pointless
>for QT subsystem, as our fmstat modules is just not used
>at all by it.
I can see hacks just for the static builds, but it is a hard way, in any
>Probably that's the reason Istvan added it.
Yes, it was a missing of the missed info.
___
Harbour mailing list (attachment size limit: 40KB)
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour
> OK, these are just the global operator redefinitions, does not affect the Qt
> interface deletes. We can comment them.
I've added the rest anyway.
What is the way to force our allocation functions to be
used by QT C++ new/delete operators?
Without this, any fm.c leak measurement is pointless
In fact the whole point of previous implementation was
that we warn developers if there _is_ a leak, and stay
silent if there isn't. This way it's apparent when there
is a problem and when not. If we wash together the
two messages, it will be less easy to spot if there is
a problem. I can imagi
. január 3. 0:37
To: Harbour Project Main Developer List.
Subject: Re: [Harbour] SF.net SVN: harbour-project:[13444] trunk/harbour
Hi,
Bisz István wrote:
> Total memory allocated: 2251241 bytes (29215 block(s))
> Warning, memory allocated but not released: 0 bytes (0 block(s))
So, let's pri
Project Main Developer List.
Subject: Re: [Harbour] SF.net SVN: harbour-project:[13444] trunk/harbour
On 2010 Jan 3, at 00:18, Bisz István wrote:
>> Maybe MinGW was the same, but it didn't report it?
>
> Personally, I reported it several times, sorry.
Until I can see a way to
Hi,
Bisz István wrote:
Total memory allocated: 2251241 bytes (29215 block(s))
Warning, memory allocated but not released: 0 bytes (0 block(s))
So, let's print a single line joined message:
Total memory allocated: 2251241 bytes (29215 block(s)), not released: 0
bytes (0 block(s))
if these
On 2010 Jan 3, at 00:18, Bisz István wrote:
>> Maybe MinGW was the same, but it didn't report it?
>
> Personally, I reported it several times, sorry.
Until I can see a way to replicating it on any
system, to me the matter stays shady.
>> Currently above msg will also appear when not compiled
0:10
To: Harbour Project Main Developer List.
Subject: Re: [Harbour] SF.net SVN: harbour-project:[13444] trunk/harbour
On 2010 Jan 2, at 23:49, Bisz István wrote:
> Hi Viktor,
>
>> I'd like to kindly ask you to elaborate more.
>
> With the previous, default build, way of the H
On 2010 Jan 2, at 23:49, Bisz István wrote:
> Hi Viktor,
>
>> I'd like to kindly ask you to elaborate more.
>
> With the previous, default build, way of the Heap managements, the HVM for
> MinGW tried to replace the CRT functions with its own malloc, free, etc.
> This is a completely wrong sol
Hi Viktor,
> I'd like to kindly ask you to elaborate more.
With the previous, default build, way of the Heap managements, the HVM for
MinGW tried to replace the CRT functions with its own malloc, free, etc.
This is a completely wrong solution in this context, is too weak.
> How about the other
> It is a summary of a long way hunting/debugging, so these short
> sentences/fragments are not adequate to describe the fix. But, as I see this
> is an usual way for fixing, without so much details.
I'd like to kindly ask you to elaborate more.
I think it's rather the opposite in ChangeLog than
: harbour-project:[13444] trunk/harbour
Hi Istvan,
> Log Message:
> ---
> 2009-01-02 21:59 UTC+0100 Istvan Bisz (istvan.bisz/at/t-online.hu)
> * /src/vm/fm.c
>* Not adequate defitions of the subsequent CRT functions for the MinGW
implemetations:
> #ifndef USE_DL_PRE
Hi Istvan,
> Log Message:
> ---
> 2009-01-02 21:59 UTC+0100 Istvan Bisz (istvan.bisz/at/t-online.hu)
> * /src/vm/fm.c
>* Not adequate defitions of the subsequent CRT functions for the MinGW
> implemetations:
> #ifndef USE_DL_PREFIX
> #define dlcalloc calloc
>
Revision: 13444
http://harbour-project.svn.sourceforge.net/harbour-project/?rev=13444&view=rev
Author: ibisz
Date: 2010-01-02 21:41:36 + (Sat, 02 Jan 2010)
Log Message:
---
2009-01-02 21:59 UTC+0100 Istvan Bisz (istvan.bisz/at/t-online.hu)
* /src/vm/fm.c
* Not ad
32 matches
Mail list logo
