I committed some code from the free-sparta branch into trunk. There were some merge problems. Unfortunately there is a memory leak which I could not locate yet.
We are working on it. Please don't report it anywhere.
Regards,
Juha
Mailing lists / lazarus / 2015-07
FreeSparta commits + a memory leak
11 messages · 5 people · –
- Maciej Izak 5
- Juha Manninen 3
- Michael Van Canneyt 1
- Ondrej Pokorny 1
- Sven Barth 1
Reply by email Subscribe to this list Your subscription
Read-only archive. Use j and k to move between messages.
Juha Manninen wrote 8 lines
I committed some code from the free-sparta branch into trunk.
There were some merge problems. Unfortunately there is a memory leak
which I could not locate yet.
We are working on it. Please don't report it anywhere.
Regards,
Juha
After your recent commits I get the following error:
To reproduce it:
1.) Hit change built mode.
2.) Select "Compiler options" -> "Additions and Overrides".
I got it on Windows and Linux (both Gtk2 and Qt AFAIR).
Revision 49526 works normally.
Unfortunately I don't have time any more to fix it by myself.
Ondrej
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus.freepascal.org/pipermail/lazarus/attachments/20150713/7d95407d/attachment-0001.html> -------------- next part --------------
A non-text attachment was scrubbed...
Name: diacacfj.png
Type: image/png
Size: 15811 bytes
Desc: not available
URL: <http://lists.lazarus.freepascal.org/pipermail/lazarus/attachments/20150713/7d95407d/attachment-0001.png>
Show quoted text 13 lines
After your recent commits I get the following error:
To reproduce it:
1.) Hit change built mode.
2.) Select "Compiler options" -> "Additions and Overrides".
I got it on Windows and Linux (both Gtk2 and Qt AFAIR).
Revision 49526 works normally.
Unfortunately I don't have time any more to fix it by myself.
you must uncomment the line 3177 from this commit:
//if NeedAlignWork thenI'am working on workaround / bug fix.
Best regards
Maciej Izak
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus.freepascal.org/pipermail/lazarus/attachments/20150713/b4ed6dc2/attachment.html>
Maciej Izak wroteyou must uncomment the line 3177 from this commit: //if NeedAlignWork then
I fixed this one. Reason for the memory leak is not found yet.
Regards,
Juha
2015-07-14 11:41 GMT+02:00 Juha Manninen :
I fixed this one. Reason for the memory leak is not found yet.
I fixed memory leak too :) :
http://svn.freepascal.org/cgi-bin/viewvc.cgi?view=revision&root=lazarus&revision=49547
execution order of initialization/finalization is not guaranteed
Best regards,
Maciej Izak
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus.freepascal.org/pipermail/lazarus/attachments/20150714/9c74f7f1/attachment.html>
2015-07-14 18:30 GMT+02:00 Maciej Izak :
execution order of initialization/finalization is not guaranteed
initialization section in LazIDEIntf was executed before initialization in PropEdits so PropertyEditorMapperList was created twice. Sometimes compiler can change execution order of initialization/finalization section (depending on uses section).
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus.freepascal.org/pipermail/lazarus/attachments/20150714/ce7ed574/attachment.html>
Maciej Izak wrote 7 lines
2015-07-14 18:30 GMT+02:00 Maciej Izak :
execution order of initialization/finalization is not guaranteed
initialization section in?LazIDEIntf was executed before initialization in PropEdits so PropertyEditorMapperList was created twice.?Sometimes compiler can change execution order of
initialization/finalization section (depending on uses section).
The uses section is the ONLY thing that determines the order. It's completely deterministic.
Michael.
"Michael Van Canneyt" wrote 11 lines
On Tue, 14 Jul 2015, Maciej Izak wrote:
> 2015-07-14 18:30 GMT+02:00 Maciej Izak :
>
> execution order of initialization/finalization is not guaranteed
>
>
> initialization section in LazIDEIntf was executed before initialization
in PropEdits so PropertyEditorMapperList was created twice. Sometimes compiler can change execution order of
Show quoted text 6 lines
> initialization/finalization section (depending on uses section).
The uses section is the ONLY thing that determines the order.
It's completely deterministic.
Deterministic yes, but not easily derivable (and also quite easy to change by accident), because /all/ uses sections need to be taken into account.
Regards,
Sven
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus.freepascal.org/pipermail/lazarus/attachments/20150714/c7d39fd8/attachment-0001.html>
The uses section is the ONLY thing that determines the order. It's completely…
2015-07-14 20:10 GMT+02:00 Michael Van Canneyt :
The uses section is the ONLY thing that determines the order. It's completely deterministic.
All is deterministic when uses section is in interface section, AFAIK if uses section is inside implementation section order is non deterministic(or difficult to predict - there may happen strange things).
Regards,
Maciej Izak
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus.freepascal.org/pipermail/lazarus/attachments/20150714/9a6fc194/attachment.html>
2015-07-14 11:41 GMT+02:00 Juha Manninen : I fixed memory leak too :) :…
Maciej Izak wroteI fixed memory leak too :) :
Thanks! You are clever.
I committed a fix in r49548. There were 2 lists, neither of them should be created in InitPropEdits.
Juha
2015-07-14 20:10 GMT+02:00 Michael Van Canneyt : All is deterministic when uses section…
Show quoted text 5 lines
All is deterministic when uses section is in interface section, AFAIK if
uses section is inside implementation section order is non deterministic(or
difficult to predict - there may happen strange things).
to be precise: in complicated case (mix of uses section in interface and implementation) is non deterministic for normal human ;). For compiler all is clear/deterministic ofc.
Regards,
Maciej Izak
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus.freepascal.org/pipermail/lazarus/attachments/20150714/4e7c4ca3/attachment.html>