Hello,
as per the subject, with heaptrc enabled, output to a file and using the
"view leaks and traces" feature of lazarus, I see several leaks, always
on the same line.
However, under linux 64 bits, the line it points to is not where the
leak is created.
Linux was reporting the leak in this
On 27/12/2020 4:00 pm, Jonas Maebe via fpc-pascal wrote:
> No. New and Dispose eventually result in calls to plain getmem/freemem
> anyway.
Thanks Jonas. I'll try and reproduce the original issue with a smaller
example. It the issue still persists (can't determine the method causing
the memory le
On 13/12/2020 22:50, Graeme Geldenhuys via fpc-pascal wrote:
> Are there any known issues with heaptrc unit via compiler parameters
> -gl -gh, when using New() and Dispose() to manually allocate and free
> memory.
No. New and Dispose eventually result in calls to plain getmem/freemem
anyway.
Jon
Hi,
Are there any known issues with heaptrc unit via compiler parameters
-gl -gh, when using New() and Dispose() to manually allocate and free
memory.
I helped someone debug their code, finding and fixing a memory leaks, but
the FPC memory leak output, after the application terminates, did not me
Am 2016-03-30 13:35, schrieb Felipe Monteiro de Carvalho:
Any ideas if I should try something else instead of heaptrc? Or any
other ideas about what to do?
I think valgrind could be of more use in this case, since it has
specific tools for profiling (not just error/leak detection):
http://val
Hello,
I have an app that is using too much RAM and I am trying to figure out
which structures are using how much RAM.
Note that this is not a leak, everything is freed nicely when the app
closes, so I am resorting to putting DumpHeap() calls somewhere. The
app has multiple threads and is fairly
> Thanks, I tried that but it still does not work. But I discovered that's
> because the program is never terminated gracefully. Stopping the
> debugger after the html page is displayed (if ran from Lazarus) or using
> Ctrl+C (if ran from the command line) does not fill heap.trc.
>
> However u
Le 26/03/2016 11:46, Graeme Geldenhuys a écrit :
add the fcl-web
source path to your project
Thanks, I tried that but it still does not work. But I discovered that's
because the program is never terminated gracefully. Stopping the
debugger after the html page is displayed (if ran from Lazarus
On 2016-03-25 22:02, Thierry B. wrote:
> Now I try fcl-web applications (curently fphttpapp) and... heaptrc does
> not work.
It's because the FCL code is not heaptrc enabled. Simply add the fcl-web
source path to your project and recompile.
Regards,
- Graeme -
--
fpGUI Toolkit - a cross-plat
Hi,
I use heaptrc unit without any problem, using Lazarus project options.
Now I try fcl-web applications (curently fphttpapp) and... heaptrc does
not work. I see the heap.trc file creation in the project directory, but
the file in simply empty.
I wonder if it is working for someone else.
-
econd manager the error
occurs and continues to grow with each page added. there is no difference code
wise just different managers
From: Jonas Maebe
To: Carver Carver ; FPC-Pascal users discussions
Sent: Friday, April 27, 2012 9:53 AM
Subject: Re: [fpc-p
On 27 Apr 2012, at 17:50, Carver Carver wrote:
> I am experiencing strange heaptrc output can someone please explain what sort
> of error could trigger this
>
> Heap dump by heaptrc unit
> 6590 memory blocks allocated : 6484894/6508528
> 6590 memory blocks freed : 6484894/6508528
> 0 unfree
I am experiencing strange heaptrc output can someone please explain what sort
of error could trigger this
Heap dump by heaptrc unit
6590 memory blocks allocated : 6484894/6508528
6590 memory blocks freed : 6484894/6508528
0 unfreed memory blocks : 0
True heap size : 229376
True free heap : 28
On 25 Oct 2010, at 11:33, Tobias Giesen wrote:
I'm trying to find a memory leak but I am unable to get a symbolic
stack trace from the heaptrc dump.
Automatically symbolicating stack traces is currently only supported
when using Stabs debug information on Mac OS X (make sure to also
compi
Hello,
I'm trying to find a memory leak but I am unable to get a symbolic
stack trace from the heaptrc dump. Also the option -Xm does not
generate a map file on Mac OS X. Or at least I don't see it.
If I could get a detailed map file with line numbers and offsets,
I would probably be happy.
Any
Thanks much for the FYI, Jonas.
Alan
On Tue, Mar 31, 2009 at 1:02 PM, Jonas Maebe wrote:
> It's a shared library issue. It has been fixed for a number of platforms in
> 2.2.4: http://bugs.freepascal.org/view.php?id=4171 (I don't know about
> Linux though, but I think so).
>
__
On 31 Mar 2009, at 20:12, Alan Krause wrote:
I am using fpc 2.2.0, and building the shared library as follows:
fpc -Sd -Cgiro -g -gh -gl -dDEBUG library.pas -Fu../path1 -Fu../path2
-Fu../path3
Am I missing anything, or is this a shared library issue?
It's a shared library issue. It has been
I've been using the heaptrc unit in DEBUG versions of my application to
detect memory leaks. However, when a memory leak is detected, it does not
include any information on the unit, line number, etc - just the hex
addresses, like this:
Heap dump by heaptrc unit
15648 memory blocks allocated : 692
On 09 Jan 2008, at 22:01, Koenraad Lelong wrote:
I made an application and I included the heaprace unit (compiled with
-gh) to check for memoryleaks. Depending on how long it runs I get
more
blocks allocated and freed. Should I worry about this ?
No.
Or is it just a
kind of counter for e
Hi,
I made an application and I included the heaprace unit (compiled with
-gh) to check for memoryleaks. Depending on how long it runs I get more
blocks allocated and freed. Should I worry about this ? Or is it just a
kind of counter for each allocation and freeing during the run of the
program ?
R
Hi,
I had a suspicion that fpGUI was leaking some memory. After
activating Heaptrc I got a bit of a shocker. I needed to log the
output to file because it was *very* long. [Yeah I know, nothing to
be proud of].
I had 522 memory leaks!! [hiding in shame] But after enabling
Heaptrc and 1 hour
Vincent Snijders a écrit :
>
> Marcel Martin wrote:
> > Hello,
> >
> > I am using fpc 1.9.5 (2004/09/15).
> >
> > There is a problem with the unit heaptrc and the routine
> > Reallocmem. For instance
> >
> > var p : PLongword;
> >
> > Reallocmem(p,1000*4);
> > ...
> > Reallocmem(p,200*4);
> Marcel Martin wrote:
>> Hello,
>>
>> I am using fpc 1.9.5 (2004/09/15).
>>
>> There is a problem with the unit heaptrc and the routine
>> Reallocmem. For instance
>>
>> var p : PLongword;
>>
>> Reallocmem(p,1000*4);
>> ...
>> Reallocmem(p,200*4); <- this instruction upset heaptrc
>>
>> Do
Hello,
I am using fpc 1.9.5 (2004/09/15).
There is a problem with the unit heaptrc and the routine
Reallocmem. For instance
var p : PLongword;
Reallocmem(p,1000*4);
...
Reallocmem(p,200*4); <- this instruction upset heaptrc
Does the problem come from Reallocmem or from the heaptrc unit
Hi,
I get the following output from heaptrc:
Heap dump by heaptrc unit
2039 memory blocks allocated : 38500/42552
2039 memory blocks freed : 38464/42504
0 unfreed memory blocks : 36
True heap size : 262144 (96 used in System startup)
True free heap : 261856
Should be : 262000
I don't how to i
25 matches
Mail list logo
