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 which you
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 will
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
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 run
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 functionality we have
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.:
myapp.exe
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 program
] 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 collects the necessary
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
To: 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 used so
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 ),
-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 released. Just simply run any
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
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 you have any
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 to
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
regarding the Heap managements.
Best regards,
István
-Original Message-
From: harbour-boun...@harbour-project.org
[mailto:harbour-boun...@harbour-project.org] On Behalf Of Viktor Szakáts
Sent: 2010. január 2. 22:58
To: Harbour Project Main Developer List.
Subject: Re: [Harbour] SF.net SVN
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
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 solution
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 Heap managements, the HVM for
MinGW tried to replace the CRT
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
with
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
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 replicating it on any
. 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 print a single
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
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
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
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
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 leak measurement is pointless
29 matches
Mail list logo
