-
Welcome to B4X forum!
B4X is a set of simple and powerful cross platform RAD tools:
- B4A (free) - Android development
- B4J (free) - Desktop and Server development
- B4i - iOS development
- B4R (free) - Arduino, ESP8266 and ESP32 development
Bug? System Out Of Memory Exception
- Thread starter Ertan
- Start date
- Similar Threads Similar Threads
What exactly are you doing? Anything special?
No, the project stays open on my own virtual server and I continue from where we left off.
I get this error and get the error "B4A Not Responding" when I process the project and do many compilations.
Then I get a "System Memory Exception" error in the compilation messages.
I think these could be piling up somewhere and causing swelling. This is how we solve it.
added... (
In addition, it was compiling a fairly long time before encountering this error. (15 seconds)
I noticed that when I restarted the project, my compiling speed increased. (5-6seconds)
)
Last edited:
There are no known memory leaks in the IDE. It can run here for weeks without the memory usage increasing.
gc.collect has nothing to do with such issues.
The way to debug it is to get a memory dump. You can use this tool to get a dump and then analyze it: https://github.com/fremag/MemoScope.Net (the x86 version).
It is also possible that your computer is low on RAM.
gc.collect has nothing to do with such issues.
The way to debug it is to get a memory dump. You can use this tool to get a dump and then analyze it: https://github.com/fremag/MemoScope.Net (the x86 version).
It is also possible that your computer is low on RAM.
You can't solve memory leaks in managed code by invoking c.collect. Invoking gc.collect will only collect any memory that the garbage collector will already reclaim - by invoking it you are just doing it earlier. Invoking gc.collect is almost never necessary, the only time I know that it is useful is when dealing with managed bitmaps where the managed memory allocation known to the garbage collector is small and there is a large native bitmap. In this case the garbage collector does not know about the large native memory allocation so invoking gc.collect will force an early reclaim of the small managed code and in doing so will free the large native allocation.
Similar Threads
