Hello,
I'm using FPC 2.4.0 on Mac and I have a problem with WideString memory leaks. Is there any known issue, such that temporary WideStrings are not always freed, or any bug in reference counting?
Cheers,
Tobias
Mailing lists / fpc-pascal / 2010-10
Widestring memory leaks with FPC 2.4.0?
19 messages · 5 people · –
- Tobias Giesen 11
- Jonas Maebe 5
- Florian Klaempfl 1
- Honza 1
- Marco van de Voort 1
Reply by email Subscribe to this list Your subscription
Read-only archive. Use j and k to move between messages.
Tobias Giesen wroteI'm using FPC 2.4.0 on Mac and I have a problem with WideString memory leaks. Is there any known issue, such that temporary WideStrings are not always freed, or any bug in reference counting?
No.
Jonas
Hi,
I am doing a regular heaptrc.DumpHeap now and I see that WideString memory blocks are still allocated for string values which are no longer in use. Is the memory freed in some lazy way? Or should a value that is no longer assigned to any WideString be freed immediately?
Cheers,
Tobias
Tobias Giesen wrote 5 lines
I am doing a regular heaptrc.DumpHeap now and I see that WideString
memory blocks are still allocated for string values which are no
longer in use. Is the memory freed in some lazy way? Or should a
value that is no longer assigned to any WideString be freed
immediately?
There can always be hidden temps around. Unless heaptrc shows leaks when the program exits, no memory leaks happen.
Jonas
Unless heaptrc shows leaks when the program exits, no memory leaks happen.
It's a leak. The program loses hundreds of MBs of memory just by working with WideStrings. I compared it against FPC 2.2.4 - no leak.
An SVN snapshot of 2.5.1 from around 3 months ago also leaks.
Will update from SVN now.
Cheers,
Tobias
In our previous episode, Tobias Giesen said:
Show quoted text 7 lines
> Unless heaptrc shows leaks when the program exits, no memory leaks
> happen.
It's a leak. The program loses hundreds of MBs of memory just by
working with WideStrings. I compared it against FPC 2.2.4 - no leak.
An SVN snapshot of 2.5.1 from around 3 months ago also leaks.
Note that on Windows 2.2.4 has the "Kylix" widestring, while 2.4.0 and later have a "COM" widestring.
It's a leak. The program loses hundreds of MBs of memory just by working with…
Tobias Giesen wroteIt's a leak. The program loses hundreds of MBs of memory just by working with WideStrings. I compared it against FPC 2.2.4 - no leak.
Then you'll have to provide a compilable example that demonstrates the problem so we can fix it.
Jonas
Then you'll have to provide a compilable example that demonstrates the problem so we can fix it.
I will try!
Cheers,
Tobias
Hi,
the latest 2.5.1 SVN leaks too (on Mac i386). Will try to isolate it.
Cheers,
Tobias
Hi,
is it possible to turn off reference counting, for a test?
Is there a difference between UnicodeString and WideString on the Mac version (i386) of FPC 2.4 / 2.5?
Cheers,
Tobias
Tobias Giesen wroteis it possible to turn off reference counting, for a test?
No.
Is there a difference between UnicodeString and WideString on the Mac version (i386) of FPC 2.4 / 2.5?
No. UnicodeString and WideString only differ on Windows.
Jonas
Hi,
I think the problem might be that Widestring reference counting is not thread safe. But it worked fine in FPC 2.2.
I will add some UniqueString calls and also try to isolate the issue.
Cheers,
Tobias
2010/10/26 Tobias Giesen :
I think the problem might be that Widestring reference counting is not thread safe. But it worked fine in FPC 2.2.
A bug may show anytime anywhere, but the built in ref counted string types are AFAIK thread safe what concerns the ref count per se. I suspect a subtle flaw in the client code is more probable.
bflm
freepascal-bits.blogspot.com
A bug may show anytime anywhere, but the built in ref counted string types are AFAIK thread safe what concerns the ref count per se. I suspect a subtle flaw in the client code is more probable.
No, it is a compiler bug. The same code works 100% perfectly on Windows using Delphi, as well as on Mac OS X using FPC 2.2. Starting with FPC 2.4, it loses memory, which can be fixed by using
UniqueString
in a number of spots in the code. That is proof enough that the compiler has a bug. I am trying to isolate it today by finding out where exactly the UniqueString is necessary.
Kind Regards,
Tobias Giesen
"To avoid a reboot, make sure that no SuperFlexible or ExtremeSync processes are running in Task Manager before installing an update."
Super Flexible Software Ltd. & Co. KG
Lessingstr. 42
48485 Neuenkirchen, Germany
www.superflexible.com
www.tgtools.com
----------------------------------------------------------- Registered at register court Steinfurt as HRA 5061 Liability / general partner: TGTools Ltd.
Company No. 05513299
Registered in England and Wales
Directors: Tobias Giesen and Claudia Giesen
Tobias Giesen wrote 7 lines
> A bug may show anytime anywhere, but the built in ref counted string
> types are AFAIK thread safe what concerns the ref count per se. I
> suspect a subtle flaw in the client code is more probable.
No, it is a compiler bug. The same code works 100% perfectly on
Windows using Delphi, as well as on Mac OS X using FPC 2.2. Starting
with FPC 2.4, it loses memory, which can be fixed by using
So without ref. counting it works.
Show quoted text 5 lines
UniqueString
in a number of spots in the code. That is proof enough that the
compiler has a bug.
It is possible, but it depends on the usage of the string.
I am trying to isolate it today by finding out where exactly the UniqueString is necessary.
Hi,
I was wrong, UniqueString does not help after all. I am now using an extended version of the heaptrc unit to show the reference count (and string value) for unfreed WideStrings and they usually have 1 as a reference count.
Will keep you posted.
Cheers,
Tobias
Hello,
I have been making tests all day long and I do not have any conclusive results. I fixed a small memory leak in my code too. This leak may have misled me to believe that the compiler has a leak. However after all the efforts, the application still uses more and more memory while it is doing its processing.
Upon exit, the memory does seem to be freed correctly now according to heaptrc. But MacOS stops giving memory to the app after a while and then it quits.
Could it be that the memory manager has been changed since FPC 2.2 and is now more susceptible to heap fragmentation?
Could there be any allocations that bypass heaptrc?
The app is allocating hundreds of Megabytes of memory over time and I still don't know how it is happening.
I can't believe that I have made zero progress in two days. Wow. Haven't had such an extreme experience in a while. Well except for trying to install Linux on my MacBook Pro 13 inch ;=)
Cheers,
Tobias
Tobias Giesen wrote 6 lines
Upon exit, the memory does seem to be freed correctly now according to
heaptrc. But MacOS stops giving memory to the app after a while and
then it quits.
Could it be that the memory manager has been changed since FPC 2.2 and
is now more susceptible to heap fragmentation?
It has been changed, but if anything it should be less susceptible to heap fragmentation.
Could there be any allocations that bypass heaptrc?
Yes, if you call external code that uses libc's malloc() family of routines to allocate memory.
The app is allocating hundreds of Megabytes of memory over time and I still don't know how it is happening.
What you can try is
a) add "cmem" to the uses clause of your program, to change from FPC's default heap manager to the libc memory manager. If that solves the problem, it's probably a heap fragmentation issue b) if that does not help (or not enough), disable heaptrc (but keep cmem) and run Valgrind's massif tool on your program. You can download Valgrind from http://valgrind.org/ and information about massif at http://valgrind.org/docs/manual/ms-manual.html
Jonas
Hi Jonas,
thanks very much!!!
I am sorry for the wrong things that I wrote. Now I can clearly see that the memory is not lost on the FPC heap. The total heap size doesn't even there's no difference with CMem either.
More work to do ...
Cheers,
Tobias