RAD Studio XE7 Enterprise, Update 1 – Out of memory
Just to clarify how extensive my memory issues are… I often have to compile at least three of these apps when testing changes. The server, the admin app, and the truck app.
I can currently compile 2.5 apps before I have to restart the IDE:P
Switching between two apps, the leak is slightly slower – but I will run out.
I usually end up doing something like this:
– Exit IDE, Restart IDE
– Compile the two apps I won’t be debugging,
– Exit IDE, Restart IDE
– Compile the app I plan to debug
– Exit IDE, Restart IDE, Start the other two apps outside the debugger.
– Run the app I plan to debug and hope the debugger doesn’t die on continue from breakpoints
…and that’s how the day passes… Dozens and dozens of restarts… and that’s on a good day.
Edit: IDE tweaks:
* No Castalia.
* -noparser on command line
* Error Insight disabled
I certainly hope you are addressing this for the next major release, Marco Cantù
I was having the same thing with XE8 but when I disabled Castalia it went away. I haven’t seen it in the Update1 of XE8 but not sure why!
* No Castalia.
* -noparser on command line
* Error Insight disabled
No IDE Fix Pack? Is MSBuild any better? Checking that MSBuild box helped me compile a large IOS app when it wouldn’t compile anymore. It wasn’t 2 million lines though.
MS Build works – but not if you want to go debug.
How much total/free memory does your computer have?
Lars Fosdal What does -noparser do? and when was it introduced?
Jimmy H 32Gb total, around 19Gb free, unless my SQL Server instances are gobbling space, but I don’t think I’ve ever been under 10Gb free.
I configured the Release and Debug configurations so that the Relase always uses MSBuild (Note that it is vital to have different DCU folders for Release and Debug for that). Then I switch only that project to Debug which I am actually debugging. Not perfect, I know, but it might help.
Another idea: Can you use an independent instance of Delphi for each project? Never tried myself, though.
Nicholas Ring I found the -noparser tip in the community, and it’s related to Error Insight too, AFAIK.
Uwe Raabe We use Continua CI and build releases directly from the repository. I have not tried the multiple IDE, but expect it to be troublesome in several areas. Shared projects files, shared rc to res files being rebuilt, shared source modification and history, editing or setting breakpoints in the right file in the wrong IDE, debugger issues, etc.
I have tried using MS Build configs, but it is cumbersome, and I miss out on hints and warnings, and it’s not for debugging.
Somewhat off topic: the IDE always uses only 1 of my 8 kernels.
Lars Fosdal Are those projects you are building part of same project group? From my experience Delphi caches all projects in same group. I don’t have large projects but I can successfully simulate OOM erros with my library that has about 20 test projects included, if I build them all Delphi usually crashes.
If you close project (project group) after build cache will be cleared. so maybe you can save yourself from restarting Delphi.
Note: last Delphi version I have tested and where I could reproduce above is XE7.
Lars Fosdal That is because they haven’t retro fitted the parallel programming library to the compiler yet 😛
Lars Fosdal I have filed bug report
Compiling multiple app projects in project group can trigger Out of Memory Error
https://quality.embarcadero.com/browse/RSP-11497
I already have similar private QC report filed more than year ago, but that was left in QC limbo with Need Feedback status, so I have decided to file new one.
Dalija Prasnikar – I’ll link my video in the comments on that QP issue. I’ll try the close project group – but – it still doesn’t solve the OOM issue when building three apps.
Upvoted it as well.
Lars Fosdal You would have to build first app, then close Project Group, then build second app, then close, then build third. Build All is recipe for disaster.
If you can successfully build several apps without OOM you can build them together, then close, then build the rest…
IDE restarts required due to memory leakage? How can this even be possible? It’s 2015, FFS. Is 20 years not enough time to get the basics right?
I just tried the same with XE 8.1.
1.7 apps before out of memory.
Lars Fosdal With or without Castalia 😛
BTW, does closing Project Group help in your case. Not that it is complete solution to the issue, but it is faster workaround than restarting complete IDE.
/nocastalia /noparser
Error Insight off
I remember being able to compile 5-6 apps in the earlier XE versions.
Closing and reopening the project group does help – but – it’s not what I want. Hopefully, this will be addressed eventually – preferably before compilation is limited to 0.9 applications.
Lars Fosdal If close/reopen helps then this part of general OOM IDE issue can be easily solved with cache clean-up between building two app projects.
Lars Fosdal I think that IDE OOM is currently the most serious issue. I also hope it will be solved soon, even though I am not experiencing it myself. But I can imagine the pain for users with large codebases.
On a sidenote: XE8 died a quick and horrible death on OOM, while XE8.1 is kind enough to fail (dis)gracefully.
Lars Fosdal How are things working with DX Seattle?
https://quality.embarcadero.com/browse/RSP-11497 has been closed as “Cannot reproduce” and I cannot retest because I don’t have it.
Our software built with #10Seattle are live at a pilot site, and so far there has been no issues (Win32). …touches wood…
As for the out of memory – I can still reproduce it – if I enable Eurekalog. Not sure if that is related to EL. It doesn’t crash out, tough.
Lars Fosdal Does it make sense to dispute the issue resolution?
Not really sure. Perhaps it is better to raise a new issue, considering the fairly extensive change in #10Seattle .
Lars Fosdal Agreed. I will leave that part to you then.