Critical Virtual Memory


We’ve been getting “hard” crashes on 17.1, looks like our application is using too much virtual memory.

Windows logs say crash is in kernelbase.ddl, but right before the crash there is a system event saying our app is using 58gig of virtual memory !

Attached are two screen shots, one from a test machine, one from deployed server. The deployed server has around 38gig of ram (but very little of that ram is used by 4D, mostly virtual memory). In the screenshot i tried to show the size of virtual memory, how much is ‘commited’ by mSupply (our 4d app) and how much 4D admin windows shows is used.

I’ve checked journal logs, and there is nothing out of the ordinary before the crash. Turned on 4d logs, will update when next crash happens.

There is limited/no info regarding 4D use of virtual memory, so it’s really hard to figure out.

Is there any way to force 4d to user ram before virtual memory ? Is there any way to ‘flush’ virtual memory ?

By the way, the data file is only 100mb.

(not resolved)

[]31308492;“Deployed Server”[/]

[]31308500;“Test machine”[/]


This looks for me like a memory leak.

If virtual memory slowly grows while an application is running and physical memory stays low, it is most likely a memory leak.
In 4D code this is often seen when a developer parses a XML and forgets to close it (this produces quickly large leaks). Opening documents without closing or creating hierarchical lists creates small leaks.

To debug start the Debug Log and insert (LOG EVENT) every 10 (later 1) minute the used physical and virtual memory (GET MEMORY STATISTICS).

Start with 10 minutes, let the server run for an hour (or a day, I don’t know how fast your memory grow) and use the log to see if it grows regulary or jumps. When you can better identify when that happens (like during the night when you run statistic processes, etc), reduce the interval. The log shows the executed code between this positions, this will help you to identify the reason.

If not, contact your local tech support and open a TAOW case.


We’ve been getting “hard” crashes on 17.1, looks like our application
is using too much virtual memory.

17.2 and 17.2 HF1 are the latest version

Just to let you know that I have a similar case with a client crash (don’t know if it’s due to a memory leak) but I already open a TAOW case :

142326 : Crash du client en tache de fond ?

It seems that the 4D widget TimePickerLCD make grow the memory usage constantly ?!

I have no response and noone is affected to my case right now :?: :-?

from experience (bad plugin code) I can testify that buffer over-run results in crash of the UI thread.

Thank you for all your help, issue is resolved.

It turns out, it was our code, misuse of plug in (xlBookCreate wasn’t always released, and this was running on a scheduler)

Combination of 4d logs, journal file and deep look at some of the methods helped to find the leak.

Thanks Thomas for most helpful comment