On Thu, Sep 3, 2009 at 4:55 AM, Jonas Maebe wrote:
> It does not detect memory leaks stemming from memory not allocated via FPC
> code. A lot of Mac OS X framework routines return pointers that you have to
> retain/release in a balanced way.
Yes, my memory leak was not about allocated blocks but r
Vincent Snijders het geskryf:
>
> It works only for memory allocated by the fpc heap manager, so a
> winapi CreateWindow call, or a gtk gtk_button_new call would create
Ah OK, I see what you mean. So does profilers like valgrind detect those?
Regards,
- Graeme -
--
fpGUI Toolkit - a cross-p
Jonas Maebe het geskryf:
>
> What do you mean?
You sometimes get loads of output highlighting several memory leaks. The
backtrace information doesn't always lead tot he exact location where
the memory leak was caused. That's the "hit and miss" I mentioned.
Sometimes the backtrace is correct and s
On Wed, Sep 02, 2009 at 06:20:17PM -0300, Felipe Monteiro de Carvalho wrote:
>
> Is anyone using a profiler in Mac OS X? I am trying to detect if there
> are memory leaks.
>
> gprof doesn't seam to work and valgrind doesn't seams usable from
> their readme, so I tryed "Sampler" from the Developer
On 03 Sep 2009, at 08:56, Graeme Geldenhuys wrote:
When the application quits, it dumps to the
console the memory leak status and a backtrace of more or less where
they got introduced. The latter is rather a 'hit and miss' situation
What do you mean?
Jonas
__
Graeme Geldenhuys schreef:
What is wrong with enabling the heaptrc unit (-gh)?
It works only for memory allocated by the fpc heap manager, so a winapi CreateWindow
call, or a gtk gtk_button_new call would create an undetected memory leak, if the
returned handle/pointer is not release properl
On 03 Sep 2009, at 08:56, Graeme Geldenhuys wrote:
What is wrong with enabling the heaptrc unit (-gh)?
It does not detect memory leaks stemming from memory not allocated via
FPC code. A lot of Mac OS X framework routines return pointers that
you have to retain/release in a balanced way.
Felipe Monteiro de Carvalho het geskryf:
>
> Is anyone using a profiler in Mac OS X? I am trying to detect if there
> are memory leaks.
As Jonas mentioned, profilers do not detect memory leaks, but rather the
performance (speed) of your code.
What is wrong with enabling the heaptrc unit (-gh)? T
On Sep 2, 2009, at 11:25 PM, Felipe Monteiro de Carvalho wrote:
On Wed, Sep 2, 2009 at 6:23 PM, Milipili wrote:
You should use Instruments from the Developper tools.
/Developper/Applications/Instruments
In my 10.4 there isn't this directory.
Available since 10.5 if I remember well.
http:
On 02 Sep 2009, at 23:20, Felipe Monteiro de Carvalho wrote:
Is anyone using a profiler in Mac OS X? I am trying to detect if there
are memory leaks.
Profilers don't detect memory leaks. Profilers detect which code is
executed (a lot) by the program.
gprof doesn't seam to work
gprof ca
Ah, but I found ObjectAlloc, which seams to work, thanks a lot =)
--
Felipe Monteiro de Carvalho
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
On Wed, Sep 2, 2009 at 6:23 PM, Milipili wrote:
> You should use Instruments from the Developper tools.
> /Developper/Applications/Instruments
In my 10.4 there isn't this directory.
--
Felipe Monteiro de Carvalho
___
fpc-pascal maillist - fpc-pascal@
On Sep 2, 2009, at 11:20 PM, Felipe Monteiro de Carvalho wrote:
Hello,
Is anyone using a profiler in Mac OS X? I am trying to detect if there
are memory leaks.
gprof doesn't seam to work and valgrind doesn't seams usable from
their readme, so I tryed "Sampler" from the Developers dir, but the
> * Hi fpc-list,
>
> I launch compilation with a key -pg for a postprocessing in gprof
> But freepascal produces an error:
> ,-[ Clipboard ]-
> | Free Pascal Compiler version 1.0.10 [2003/06/27] for i386
> | Copyright (c) 1993-2003 by Florian Klaempfl
> | d:\pascal\pp\bin\win32\ldw.exe: can
14 matches
Mail list logo
