Does anyone else experience OutOfMemory proplem with Delphi Berlin? This is ridiculous. Making the IDE 3GB ready and not being able to fix memory leaks. Pathetic.
No such problems here. During compilation of a project group the memory might go up to some 1-2 GB but drops down again after closing it. I never got any OutOfMemory. On the other hand, it might be much easier to make an application large address aware than finding and fixing all memory leaks. I don't see anything pathetic in this.
It's obviously much easier to make the process large address aware. Tackling excessive memory use of much harder. I think that have done both but it would not be surprising if more needs to be done. I think that we all have different experiences because we have different input data. Many people will wonder what all this talk of memory leaks is of. And other people were crippled by it.
It woudn't be pathetetic if the problem didn't last for years and hadn't be occasuanlyy fixed by Andreas Hausladen who doesn't even have the source code.
Are you building multiple projects at the same time? IDE does not have leak as leak, but it caches every project (application) data separately, unless you build a library.
I will investigate it more, but for now it looks like a problem of the win32 debugger. The sequence of actions is the following. 1. Change something in the code. 2. Compile the project for the kernel.dll. (The project group also includes other dlls and the main exe, which basically only calls the Start function in the kernel.dll) (if it matters). 3. Run the app with debugging. 4. Debug the code. 5. Exit with Ctrl+F2. 6. Repeat. Eventually the bds.exe occupies all of the 3GB space and either the debugger doesn't work, or the compiler doesn't work, and often you can not even close the IDE, It just doesn't close.
I have similar issues with the Win 64bit debugger (Berlin update 2). One of the dbkw64_24_0.exe processes increase in memory for each time I run the debugger. As there is no memory limitation for the 64bit debugger, it will continue until it has grabbed most of my 16GB of RAM if I do not restart Delphi. So nowadays I restart it a few times a day...
Attila Kovacs Closing the app the right way instead of Ctrl+F2 doesn't make any difference. The number of descriptors, GDI objects, User objects of the bds.exe doesn't change much.
4GB on 64 bit OS.
ReplyDeleteNo such problems here. During compilation of a project group the memory might go up to some 1-2 GB but drops down again after closing it. I never got any OutOfMemory. On the other hand, it might be much easier to make an application large address aware than finding and fixing all memory leaks. I don't see anything pathetic in this.
ReplyDeleteIt's obviously much easier to make the process large address aware. Tackling excessive memory use of much harder. I think that have done both but it would not be surprising if more needs to be done. I think that we all have different experiences because we have different input data. Many people will wonder what all this talk of memory leaks is of. And other people were crippled by it.
ReplyDeleteVitali Burkov Have you submitted a bug report?
It woudn't be pathetetic if the problem didn't last for years and hadn't be occasuanlyy fixed by Andreas Hausladen who doesn't even have the source code.
ReplyDeleteThe funny thing is that often all kinds of problems in the IDE are caused by all sorts of third party packages or experts.
ReplyDeleteAre you building multiple projects at the same time?
ReplyDeleteIDE does not have leak as leak, but it caches every project (application) data separately, unless you build a library.
I will investigate it more, but for now it looks like a problem of the win32 debugger. The sequence of actions is the following.
ReplyDelete1. Change something in the code.
2. Compile the project for the kernel.dll. (The project group also includes other dlls and the main exe, which basically only calls the Start function in the kernel.dll) (if it matters).
3. Run the app with debugging.
4. Debug the code.
5. Exit with Ctrl+F2.
6. Repeat.
Eventually the bds.exe occupies all of the 3GB space and either the debugger doesn't work, or the compiler doesn't work, and often you can not even close the IDE, It just doesn't close.
Win + R, pskill bds
ReplyDeleteA series of keystrokes etched into my muscle memory.........
youtube.com - Delphi 10.1 Berlin EOutOfMemory issue
ReplyDeleteSo I captured it. Looks like a win32 compiler bug after all. The incremental compiling seems to leak the memory.
No, somehow it is related to debugging. If I just change the code and compile, everything is ok.
ReplyDeleteI have similar issues with the Win 64bit debugger (Berlin update 2). One of the dbkw64_24_0.exe processes increase in memory for each time I run the debugger. As there is no memory limitation for the 64bit debugger, it will continue until it has grabbed most of my 16GB of RAM if I do not restart Delphi. So nowadays I restart it a few times a day...
ReplyDeleteI've made a ticket,
ReplyDeletehttps://quality.embarcadero.com/browse/RSP-16784
Attila Kovacs always
ReplyDeleteAttila Kovacs I'll try tomorrow
ReplyDeleteAttila Kovacs Closing the app the right way instead of Ctrl+F2 doesn't make any difference. The number of descriptors, GDI objects, User objects of the bds.exe doesn't change much.
ReplyDelete