I wonder if it's some stupid windows 10 update for specter or that other damn thing with the CPUs...some times (I've seen it mostly in older windows eg xp,vista etc) you got an out of memory when the system run out of resources. You can test against resources if you login in safemode and run build from there. If that succeeds then some recently install application or service consumes to many resources. If not then try installing a clean system on a VM with older windows (7 comes to mind) and see if that helps at all.
The strange thing is that it seems to be a linker/compiler errorI tried internal linker -Xi and error was still there. Then I tried external linker with -Xe and error was gone both in Optimized IDE and Normal IDE profile build modes. I checked several times and I can reproduce on will. It is too late now so I will do further testing tomorrow, but right now it looks to me as this is a work around. Another work around is not just check "Clean all" in already mentioned build modes (which I wrongly asumed was enough), but to use last "Clean up + Build all" profile for building IDE. That solved the problem until next build is needed, but it was too slow to do it every time so I looked further as you could see.
Try using the -CX option in the Lazarus Build.It didn't help.
Avra, are you by chance using any type of AMD CPU?No, Intel i5 4670.
Have you tried to remove the overclocking? Also try underclocking the cpu and memory speeds.No overclocking. BIOS defaults for CPU and MEM. MemTest86+ runs rock solid.
Test your memory with these programs : http://www.memtest.org/ https://www.memtest86.com/
maybe its not worth anything but, did you go into the Settings:Updates /Security, scroll downI am in developer mode, if that is what you wanted me to check.
where it says developer mode and make sure you have some lead way there?
Have you tried shutting down the IDE between package install
and also check the Task manager for running apps related to Laz between shutdowns.
Have you tried shutting down the IDE between package installRestarting IDE does not solve the problem.
check the Task manager for running apps related to Laz between shutdowns.Single Lazarus executable in task manager, no hanging executables.
As I mentioned before the optimized profile seems to work around the issue whatever it really is.In my case it just gave more room before it strikes again. My guess is that it will strike you too if you install another 10-15 packages. If you need bunch of packages for testing then you can use these: https://bitbucket.org/avra/ct4laz/downloads/ct4laz-preview.zip.
As I mentioned before the optimized profile seems to work around the issue whatever it really is.In my case it just gave more room before it strikes again. My guess is that it will strike you too if you install another 10-15 packages. If you need bunch of packages for testing then you can use these: https://bitbucket.org/avra/ct4laz/downloads/ct4laz-preview.zip.
The only permanent work around so far is to use external linker (add -Xe in active build profile). I have so many packages installed that at the moment I remove -Xe and try to rebuild IDE, "No memory left" error shows every time. So yes, so far I can reproduce it whenever needed.
WOW64 enables 32-bit applications to take advantage of the 64-bit kernel. Therefore, 32-bit applications can use a larger number of kernel handles and window handles. However, 32-bit applications may not be able to create as many threads under WOW64 as they can when running natively on x86-based systems because WOW64 allocates an additional 64-bit stack (usually 512 KB) for each thread. In addition, some amount of address space is reserved for WOW64 itself and the data structures it uses. The amount reserved depends on the processor; more is reserved on the Intel Itanium than on the x64 or ARM64 processors.
If the application has the IMAGE_FILE_LARGE_ADDRESS_AWARE flag set in the image header, each 32-bit application receives 4 GB of virtual address space in the WOW64 environment. If the IMAGE_FILE_LARGE_ADDRESS_AWARE flag is not set, each 32-bit application receives 2 GB of virtual address space in the WOW64 environment.
Maybe an old Bug 0031517 ?!No, sorry. Adding {$setpeflags $20} does not help with "No memory left" error. I have even tried to set {$MAXSTACKSIZE 512000000} for win32 but that didn't help either. Thank you for your input.
Maybe some security software enforces some memory limit ?That's a possibility. Personally I use the lightweight Microsoft Security Essentials, both FPC and Lazarus directories are white listed.
Maybe some security software enforces some memory limit ?
I thought on 32 bits machines limit was 4GB allocation more or less... It happens around 2GB to HANGBTW: On Windows (win32 parte) you can use more than 2G RAM if you declare it to the system in the PE -Header.
I thought on 32 bits machines limit was 4GB allocation more or less... It happens around 2GB to HANGBTW: On Windows (win32 parte) you can use more than 2G RAM if you declare it to the system in the PE -Header.
I have 24 GB RAM on my machine, but in win32 this is meaningless. Can you share the code for tests ?
Andreas
It looks like the issue is not just an isolated bug, triggered by some strange settings. @avra since you're able to reproduce with 100% accuracy, can you please run a few tests with FPC 3.0.2 and Lazarus Trunk?I have used fpcupdeluxe to install FPC 3.0.2 + TrunkLaz and after adding zillion packages I was able to get "No memory left". Again, using external linker for IDE rebuild (-Xe switch) helped.
It's likely related to a windows 10 patch for one of those CPU vulnerabilities or some other "issue" LOLDefinitly no, i have fighted again the memory left issue long time before. See the bug report. And i have spent a lot of time to understand, why this issue rises.
IMHO rises the issu because the programms are bigger at linktime and reaches more and more the 2GB Barrier. If the enviroment goes to win64 and cross compile to win 32 the issue will gone.I agree that some limit is reached, but remember that patch you have proposed does not solve "No memory left" error in my case.
Andreas insisted via mail that I should try to recompile FPC with PP.PAS fix, so I did it once more:Unfortunately after that Lazarus still had "No memory left" error on recompilation (when not using -Xe switch), although \myfpcsrcdir\compiler\ppc386.exe had IMAGE_FILE_LARGE_ADDRESS_AWARE flag when checked with pse32.exe (as suggested by Andreas). This time I searched for all ppc386 executables in my fpc/laz dir and there were 3. Besides already mentioned one there was one in fpcbootstrap dir and one in \fpc\bin\i386-win32 dir. When last one was replaced with new ppc386.exe which has IMAGE_FILE_LARGE_ADDRESS_AWARE, the error does not show any more. I can repeat the error simply by putting original ppc386.exe back in place. The reason why I originally thought that suggested fix was not working was that my Lazarus installation was actually using different ppc386.exe from the one I thought it used. Silly me.
cd \myfpcsrcdir make clean make all make install
So, Andreas was right from the start and {$setpeflags $20} fix does help. I am really glad this fix ended up in 3.1.1, but I think it should be back ported for 3.0.6.
To summarize, "No memory left" error during Lazarus recompilation can be solved by applying the mentioned compiler fix, or by using -Xe switch in Lazarus build profile.
Thank you Andreas for your persistence and assistance!
avra, could you attach the changed ppc386.exe file for me to test?Here it is: http://anonfile.com/69IdS2dcb2/ppc386.7z
avra, could you attach the changed ppc386.exe file for me to test?Here it is: http://anonfile.com/69IdS2dcb2/ppc386.7z
Thanks Avra, but it did not work.Sorry, I use fixes for both (1.8.3 + 3.0.5). Anyway, you can make it yourself if you patch pp.pas as Andreas mentioned and follow command line make instructions that you have already quoted. Alternativelly, without any patching you can use -Xe switch in your build profile and problem is solved.
I am using Lazarus 1.8.2 + fpc 3.0.4, is this ppc386.exe you attached to this version?
Thanks Avra, but it did not work.Sorry, I use fixes for both (1.8.3 + 3.0.5). Anyway, you can make it yourself if you patch pp.pas as Andreas mentioned and follow command line make instructions that you have already quoted. Alternativelly, without any patching you can use -Xe switch in your build profile and problem is solved.
I am using Lazarus 1.8.2 + fpc 3.0.4, is this ppc386.exe you attached to this version?
armandobaza, the best way is to compile the fpc by yourself. The line to insert is descript in the bugreport Bug 0031517 (see my post of the code in this thread one page before)
The line to insert in the code of the pp.pas is now near line 170. pp.pas is in the <fpc-sources>/compiler
This patch is ONLY for WIN32 (and meaningless for WIN64 and the other plattforms)
{ Don't care about minstacksize or maxstacksize not beeing supported by current OS } {$WARN 2077 OFF} {$WARN 2078 OFF} {$ifdef win32} { 256 MB stack } { under windows the stack can't grow } {$MAXSTACKSIZE 256000000} {$setpeflags $20} // <------------------------------------here, this line is inserted {$else win32} {$ifdef win64}
Are you able to build fpc from the sources ? If not, look for fpcupdeluxe. It is a swiss-army-knife for building fpc&lazarus.
Andreas
Is there any set like {$setpeflags $20} for ARM Pi3.You might try to put -Xe switch into your current build profile.
I have asked on the mailinglist of freepascal for backporting the fix.Thank you very much!
I have asked on the mailinglist of freepascal for backporting the fix. Because i think more and more people using the stable win32 Lazarus will come into troubles. And the OPM is definitly a good tool to make bigger Ide's :-)
Andreas
sudo swapoff -aNormally the defaultvalue is 100, i have rised to 1000, and now the problems with compiling and linking of lazarus on the RasPi3B are gone.
sudo nano /etc/dphys-swapfile
sudo swapon -a