Watch, Follow, &
Connect with Us
Public Report
Report From: Delphi-BCB/IDE/Memory Issues    [ Add a report in this area ]  
Report #:  78465   Status: Closed
Out of memory when compling big projects from Delphi IDE under Wow64
Project:  Delphi Build #:  14.0.3513.24210
Version:    14.0 Submitted By:   Michel Terrisse Terrisse
Report Type:  Crash / Data loss / Total failure Date Reported:  10/8/2009 3:25:45 AM
Severity:    Commonly encountered problem Last Updated: 4/15/2014 6:49:54 PM
Platform:    All versions Internal Tracking #:   20894
Resolution: Duplicate (Resolution Comments) Resolved in Build: : XE6
Duplicate of:  95668
Voting and Rating
Overall Rating: (10 Total Ratings)
5.00 out of 5
Total Votes: 43
Description
Hello,

I use Windows 7 64 bits with 16 GB RAM.
I need to build a project group that contains 10 projects, each project referencing about 4000 delphi units (more than 3000000 lines of code for each project).
Building from the command line with MsBuild works fine. But when I try to build from the IDE, the memory increases until 1.5 GB and the compilation fails with the error F2046, out of memory.
I could read we can increase the size of the virtual space allocated for a 32 bits process under Wow64 to 4 GB if LARGEADDRESSAWARE is present in the coff header of the executable, see http://bilbroblog.com/wow64/hidden-secrets-of-w0w64-ndash-large-address-space/
Unfortunally the command
  editbin /LARGEADDRESSAWARE bds.exe
corrupts the executable.
So could you please add LARGEADDRESSAWARE at compile time when you build bds.exe ?
Ideally the best would be to have a 64 bits version of Delphi, I hope this will come soon.

Regards,

Michel
Steps to Reproduce:
None
Workarounds
Compile only one project at a time, and close and reopen Delphi before swithing to another project ...
Attachment
None
Comments

Michel Terrisse Terrisse at 8/11/2010 7:52:12 AM -
I could read somewhere that you could add those lines in the Delphi code of the IDE :

const
  IMAGE_FILE_LARGE_ADDRESS_AWARE = $0020;
{$SetPEFlags IMAGE_FILE_LARGE_ADDRESS_AWARE}

This would give more memory for the 32-bit IDE on a 64-bit version of Windows.

Michel

Michel Terrisse Terrisse at 10/31/2011 6:13:04 AM -
Same thing with Delphi XE2 update 1.

Regards,

Michel Terrisse

Angelo Crabolu at 4/17/2012 1:00:16 AM -
You get the same error even if you compilie twice a big project in a project group

Alexandre Poloziouk at 10/12/2012 9:30:10 AM -
We just migrated from Delphi 2009 to XE3 and immediately encountered this issue.

All it takes is to rebuild one of the large projects withing project group two or three times.

Windows 7 64bit as well.

Alex

Michel Terrisse Terrisse at 6/5/2012 3:05:20 AM -
Hello,

Delphi XE2 update 4.
I tried to use "Large Address Aware.exe"
  http://www.techpowerup.com/forums/showthread.php?t=112556
to add the LAA flag.
But this breaks bds.exe, probably because of the digital signature.
It would be great if you could add this flag when compiling bds.exe. Just one line in your code and developping with Delphi would be much more comfortable.

Regards,

Michel

Per Albrektsen at 9/18/2012 4:36:10 AM -
Hi

We seem to have the exact same problem on XE3, failing with F2046, but runs smoothly using MsBuild. Running Windows 7 64 bits OS.

Tried to make bds.exe large address aware but hereafter we ran into license problems :-(

A bit worrying nothing has been done on this matter - the IDE reports out of memory quite often. This doesnt happen in XE !!!

BR Per

Michel Terrisse Terrisse at 10/4/2012 1:08:26 AM -
We are moving to Delphi XE3 and this problem gets worse than ever.
We disabled all the following packages to limit memory usage :
    applet170.bpl
    DataExplorerDBXPlugin170.bpl
    DataExplorerDBXPluginInt170.bpl
    DataExplorerService170.bpl
    dcl31w170.bpl
    dclado170.bpl
    dclbde170.bpl
    dclbindcomp170.bpl
    dclbindcompdbx170.bpl
    dclbindcompfmx170.bpl
    dclbindcompvcl170.bpl
    dclCloudService170.bpl
    dcldbx170.bpl
    dcldbxcds170.bpl
    dclDBXDrivers170.bpl
    dclDBXDriversInt170.bpl
    dclib170.bpl
    dclIndyCore170.bpl
    dclIndyProtocols170.bpl
    dclIntraweb_140_170.bpl
    dclIPIndyImpl170.bpl
    dclmcn170.bpl
    dclMetropolisUILiveTile170.bpl
    dclmid170.bpl
    dclmlwiz170.bpl
    dcloffice2k170.bpl
    dclofficexp170.bpl
    dclribbon170.bpl
    dclsmp170.bpl
    dcltouch170.bpl
    dclwbm170.bpl
    dclwebsnap170.bpl
    samplevisualizers170.bpl
    CodeSiteExpressPkg_Design170.bpl

Here is memory reported by the task manager (Working set) when using Delphi :

Starting bds.exe               :   13756 KB
Maximize the main Window       :   23748 KB
Open our project group         :   55788 KB
Build one project (Shift + F9) : 1084988 KB
Run and stop the project       : 1090860 KB
Again                          : 1093112 KB
Again                          : 1094788 KB
Again                          : 1095756 KB
Again                          : 1096836 KB
Close all                      :  276032 KB

Of course we cannot build and run two projects in this project group in the same IDE, we need to run Delphi twice to do this.

Regards,

Michel

Nils Dzubiel at 11/19/2012 11:11:08 AM -
Well, I have a similar problem - only that the IDE is using  800 MB and telling me out of memory all the time - also I get RLINK errors out of memory - the only thing you can do
is close your eyes and pray ...

Here are my QCs:

110395
110624
110592
110588
110587
110586
110541
110466
110452
110451
110412
110403
110400
110395
110382

Nils

Guy Glirbas at 11/2/2012 1:26:31 PM -
It seems to me that it is time for BDS.EXE to become a 64 bit application itself.  I am starting to get out of memory errors compiling our largest project by itself.  BDS.EXE is hovering around 1.6 GB (virtual size according to Process Explorer) for me most of the time.

Guy Glirbas at 11/2/2012 1:28:00 PM -
I'm running XE3 with Developer RExpress, ReportBuilder, RemObject Hydra, and our own Design-time packages.  Loading all those packages must contribute a bunch to the memory consumed.  Then start compiling...

Alexandre Poloziouk at 12/4/2012 2:19:29 PM -
Guy,

We have pretty large project as well and using most (if not all) of DevEx Delphi components and a lot of other heavy stuff as well.

Funny enough I can compile entire DevEx components set from inside IDE just fine - that is over 170+ .dpks  with over 30Mb of .pas files yet when I try to compile one of our own packages which is only 1.5Mb in size XE3 IDE will go "out of memory" right after second build/rebuild of this project!

That leads me to believe that this issue has nothing to do with the size itself.
The project I mentioned uses generics and collections extensively and this appears to be the issue with XE3.

Same project can be rebuild/build all day long inside D2009 and XE2 IDEs without any issues.

Hope it helps (but most likely will be ignored by Embarcadero as usual).

Alex

Michel Terrisse Terrisse at 4/8/2013 6:43:42 AM -
Hello,

We could find that refactoring is responsible of increasing memory each time we run the debugger.
Just remove the Refactoring menu with
[HKEY_CURRENT_USER\Software\Embarcadero\<YOUR CONFIG>\10.0\Known IDE Packages]
"$(BDS)\\bin\\refactoride170.bpl"=-

and remove the *.identcache files, and the memory stops growing up and up each time you start the debugger.

Michel

Peter Johnson at 5/2/2013 2:53:07 PM -
Problem still there in XE4 Pro (without iOS pack).

Using Win7 64 bit, 16Gb laptop.

Project group has two projects. One is a small unit test project. The second is quite large: it uses about 450 units and makes significant use of generics.

Main project will build with Shift+F9 - the generated exe runs.
But the out of memory error occurs when built with Ctrl+F9 or when trying to run within or without debugger with F9 or Ctrl+Shift+F9.

Smaller project, which uses DUnit, compiles and runs OK.

Would love to see this fixed because I can't debug the project at all.

Back to my beloved Delphi 2010 for now.

BTW - same problem in XE2 and XE3, but not XE.

Tomohiro Takahashi at 6/19/2013 6:19:12 PM -
Thanks for the information. I re-opened this report.

Bernd Baumanns at 6/25/2013 4:12:37 AM -
Hello,

we have the same issue as described above (we have many generic classes, too). Usually Shift+F9 solves the issue, but not always. In such a case I kill the ide with "taskkill /F /IM bds.exe", start it again and everythings works fine.

It's really strange.

Michel Terrisse Terrisse at 7/1/2013 7:02:59 AM -
Hello,

We moved to Delphi XE4 update 1 and the bug is fixed.
Thank you very much.

Regards,

Michel Terrisse

Martir Millan at 7/7/2013 10:22:29 AM -
I have he same problem. Out of memory error.
After XE4 Update 1, there is crash instead out of memory. Several projects (10) in a Project group, build all and for each Project compilation, memory increases a lot until crash (about 1.5gigabytes).

Jason Wharton at 9/5/2013 10:59:22 PM -
I am getting this error in my version of XE3 even with a rather small project. This is extremely annoying and in my case I am certain there isn't a circular unit reference going on because there is only one small form in the project and only one project in the group.

Daniel Wischnewski at 10/9/2013 1:02:32 AM -
This problem still exists on Delphi XE4 Update 1, even with fairly medium sized project: 1.3 Mio lines of code, first compile is not working.

Command works, but this does not allow me to use the debugger. If I would have know of the problem, I might not have considered updating at all.

64 Bit was my main reason to move on, iOS was a nice touch to it.

Artjom N. at 11/21/2013 3:46:25 AM -
Hi Guys,

any news on whether this error still exists in XE5?
We have this error too in large packages that use a bunch of generics.
The only way that we can bypass this error, is to restart the BDS and compile again and hope.

Yusuf Zorlu at 3/3/2014 2:48:18 AM -
We're working also with XE5 and having this crazy problem. I can't work as i want with the IDE.

Trying the registry-fix works not for us and also using DevExtensions with Compilation / Release compiler unit cache of other projects before compiling is not working.

When can we expect a fix for this from embarcadero ... it is frustrating that we have to kill bds.exe everytime

Peter Johnson at 3/9/2014 12:54:06 PM -
Still having out of memory problems with my CodeSnip project (http://codesnip.delphidabbler.com/) even after installing Delphi XE4 update 1 (pro).

Will compile in the IDE if I do a full build, but attempting to run the project from the IDE (whether in the debugger or not) fails with the out of memory error F2046.

When can we expect a fix? It's ridiculous how long this is taking to resolve.

Yusuf Zorlu at 3/18/2014 12:32:42 AM -
Why is this problem resolved in linked ticket?? This problem is not solved, also with XE5 Update 2 the IDE consumes more and more ram and i can only compile my project 2 or 3 times, after that i have to close the ide and restart it again.

What the hell is going on at embarcadero, why nobody is looking into this problem? I'm really frustated, we're paying money and investigating a lot of time to open, close , open close the ide, this is also money for us.

Someone hearing me ???

Artjom N. at 3/18/2014 2:34:42 AM -
I'm hearing you!

We also frustrated about this issue.
It's like 60% of work time goes into delphi to close/reopen/compile -> close/reopen/compile again.

I think generics are the main problem here. If you use a lot of generic code, there is a lot of memory overhead in the bds.exe.

EMBARCADERO PLEASE do more bugfixes for delphi and c++ instead of creating new fluffy stuff for firemonkey. It's a dead end. :(

Yusuf Zorlu at 4/8/2014 2:37:57 AM -
;-( Seems that no one at embarcadero is hearing us ...

Christophe Ravaut at 4/8/2014 3:06:37 AM -
see http://www.tpersistent.com/?p=966

Yusuf Zorlu at 4/8/2014 5:33:29 AM -
And where can we find the fix? I can't see the q#, it's not available to the public?

Christophe Ravaut at 4/8/2014 6:07:29 AM -
I hope it will fixed in XE6. But now a workaround.
http://www.tpersistent.com/?p=912

Artjom N. at 4/9/2014 1:50:52 AM -
I have been working for half a year with DDevExtensions with this compiler settings. For me nothing changed. Still get this error.
It's because you compile one large Project with thousands of units. There's no need to release the unit cache of other projects. Because there is none!
A solution propably would be if you split this large project to smaller projects. Or Embarcadero fix this memory issue or they release a 64Bit Version of the Compiler/IDE.
But what it looks like they put their energy to build something like new VCL-Styles or FMX stuff. What about the fundamental? Bugfixes! :(

Yusuf Zorlu at 4/15/2014 10:59:31 PM -
Now ebd is saying that this bug is fixed in XE6. Who knows ? I do not believe in that ... the guys at embarcadero are doing lot of new stuf with android and fmx and so on .. i am really not happy. What is with our XE5? We have buyed XE5 4-5 months ago and now we should update as soon as xe6 is available , pay again money without the knowledge of bugs are really fixed or new bugs are in the system.

We have only one big project, no project groups, one project which is not compiling any more if we have already compiled 1 or 2 times. Also the fix with dcc_forceexecute is not a solution and is not working on our side. We have tested every possible fix / solution but the ide is consuming more an more memory and we're seeing different problems with the ide itself when the mem-consumption is more than round about 850mb ...

Tomohiro Takahashi at 4/16/2014 6:15:08 PM -
How about integrated MSBuild option in Delphi XE6 ?

[What's New in Delphi and C++Builder XE6]
http://docwiki.embarcadero.com/RADStudio/XE6/en/What%27s_New_in_Delphi_and_C%2B%2BBuilder_XE6#New_Option_on_the_Delphi_Compiler
-----------
New Option on the Delphi Compiler
The new Use MSBuild externally to compile option on the Delphi Compiler page sets your project to be built outside the IDE using MSBuild. This option is False by default. To enable this option, choose Project > Options | Delphi Compiler .
This new option solves an Out of Memory problem that might occur when you build extremely large projects consisting of applications and libraries.
-----------

Artjom N. at 4/17/2014 6:14:45 AM -
Oh I think It's not working for me because I have installed only a Trial Version of XE6.
I wanted to see if this Out of Memory problem is solved. And now I need a full Version to check this. Nice move ;)
That's a classic dilemma.

Artjom N. at 4/17/2014 3:23:05 AM -
When I set up this option for a project that is a package instead of an application, then a file not found error occurs. I have the german version. Here's the error:

"Package Package1.bpl kann nicht geladen werden.
Das System kann die angegebene Datei nicht finden"

"[Fataler Fehler] Package Package1.bpl kann nicht geladen werden.
Das System kann die angegebene Datei nicht finden"

Simple to reproduce:
File->New->Package->Set up the MSBuild Option->Compile

Or is this MSBuild feature only for Application-Projects?

Artjom N. at 4/29/2014 1:17:19 AM -
Why is this Report closed?
This Error still exists in XE6!

Tomohiro Takahashi at 4/29/2014 3:25:40 AM -
Please put new QC report for Delphi XE6.

Christophe Ravaut at 4/29/2014 4:21:34 AM -
Status: Closed.
But it is not solved for this report 78465. Because for XE5 we have this problem.
Will this meaning: 'We want solve this problem. Buy new version' or 'We don't care about previous versions.'

Yusuf Zorlu at 4/29/2014 2:54:58 AM -
I was not able to test XE6 .. now i can save my time to test this in XE6 by downloading an evaluation.
S..t happens and its stressing a lot, that nothing happens.

Hello someone at Embarcadero: We want a bugfix also for XE5 !!

Guy Glirbas at 4/14/2015 11:56:38 AM -
We still get Out of Memory frequently when compiling our large project in Delphi XE7 (64 bit mode or 32 bit mode).  Generally, I have to restart Delphi about every 20 minutes.

It is great that we can build our application to be 64 bit so our users do not run out of memory, but it would be nice if we developers could have that same great experience of working in a 64 bit IDE.

Server Response from: ETNACODE01