Godot Editor Crash on Ubuntu: Stop Freezes When Memory Runs Low

The freeze you actually see

You open a large project on Ubuntu, the editor shows Importing resources..., and the progress bar stalls around 60 or 80 percent. The fan spins up, the mouse stutters, Alt plus Tab stops responding, and after a minute the Godot window is gone. If you launched the editor from a terminal, you see one word and nothing else.

Killed

If you check the system log after the reboot or relog, you find the line the kernel left behind:

Out of memory: Killed process 8152 (Godot_editor) total-vm:20123456kB, anon-rss:11892432kB

This walkthrough applies to Godot 4.2 through 4.4 stable on Ubuntu 22.04 LTS and 24.04 LTS. Godot 3.x hits the same OS limit, but its import cache lives in a .import folder instead of .godot/imported, so the cleanup paths below differ. The Ubuntu memory steps are the same.

Why Ubuntu kills the editor instead of slowing down

Large imports create a short memory peak. Godot scans every file, decodes textures and audio to build import previews, writes compressed versions to .godot/imported, and keeps progress in RAM. A folder with 4K textures, uncompressed WAV files, or a copied Library from another engine can spike 6 to 12 GB for a minute even if the finished project is small.

Ubuntu has to protect the whole desktop when RAM fills. What happens next depends on swap and the out of memory manager:

• With little or no swap, the kernel has no room to page out idle browser tabs or GNOME Shell buffers, so everything locks at once.
• With swap plus systemd-oomd, which is enabled on desktop installs of 22.04 LTS and tuned further in 24.04 LTS, Ubuntu kills the largest offender, usually Godot_editor, so the desktop survives.
• With a corrupt import cache, the next open replays the same heavy import and crashes again even when free RAM looks fine.

If you only watch htop, you will miss the distinction. Check swap first, then the OOM log, then the import log. That order tells you which fix to apply.

Three common variants of the same symptom

1. Whole desktop locks during import

The mouse freezes, disk activity stops, and even Ctrl plus Alt plus T does nothing. After a hard reboot, free -h shows 8 or 16 GB of RAM but Swap: 0B, and swapon --show prints nothing. Canonical cloud images, dual boot installs with manual partitioning, and systems with encrypted ZFS often end up this way.

Do not add kernel boot flags here. This variant is a missing cushion, not a Godot bug.

2. Editor is killed but Ubuntu keeps running

This is the most common report on 24.04 LTS. The import reaches 70 percent, the Godot window disappears, and Firefox and Files keep running. Running this shows the kill:

journalctl -b -0 | grep -i oom

You will see systemd-oomd and Godot_editor on the same line. A second check confirms the peak:

dmesg -T | grep -i "out of memory"

If both point to Godot and swap was under 4 GB, treat it as pressure plus peak, and fix both sides.

3. Import finishes once, then every reopen crashes

Memory looks normal, swap exists, yet opening the project always stalls on the same .png, .exr, or .wav. Open godot.log in ~/.local/share/godot/app_userdata/YourProject/logs/ and you see the same file listed before the abort. The .godot/imported entry for that file is incomplete, so Godot retries the expensive decode on every launch.

This variant is easy to confuse with a leak. A true runtime leak grows while the game runs, which is what orphan nodes before they slow your game covers. A reopen crash that names the same import file is a cache problem, not a script problem.

Fix: give Ubuntu room, then lower the import peak

Work through these in order. Stop when imports finish cleanly.

1. Check baseline before you change anything.

free -h
swapon --show
nproc

Note RAM, swap total, and CPU count. If swap is 0B or 2 GB on a 16 GB machine, fix swap first.

1. Add a swapfile if you have the disk space. An 8 GB file is a practical starting point for 16 GB of RAM.

sudo fallocate -l 8G /swapfile
sudo chmod 600 /swapfile
sudo mkswap /swapfile
sudo swapon /swapfile

Add it to /etc/fstab so it survives reboot, then verify with free -h. Keep the default vm.swappiness of 60 on desktop. Setting it to 10 makes freezes worse because Ubuntu holds RAM too long.

1. Close the heavy neighbors before a big first import. A browser with video tabs, Discord, OBS, and a second Godot project can use more RAM than the import itself. Import with only Godot running.

1. Split the first import into batches. Move half of the raw asset folders out of the project, open the project and let it import, close the editor, move the next batch back, and reopen. If you use Godot MCP Studio to inspect the project while you troubleshoot, keep those checks for after the import finishes so you do not add pressure during the peak.

1. Keep unneeded bulk out of the scan. Put source PSD files, recordings, and backups outside res://, or place an empty file named .gdignore in any folder Godot should skip. This is also a good time to adopt a reusable Godot project template layout so raw drops land outside the import path by default.

1. Lower per file cost for the worst offenders. In the Import dock, select large textures and use VRAM compression with mipmaps off for pixel art, and convert long WAV dialogue to Ogg Vorbis or MP3 unless you need lossless editing. Reimport one folder at a time.

1. Clear a stuck cache only when Variant 3 points there. Close Godot, back up the project, delete .godot/imported and .godot/editor, keep project.godot and your res:// files, then reopen and import in batches. Do not delete the whole project folder.

Tip: import while watching free -h in a terminal on a second workspace. If available drops to near zero right before the kill, it is pressure. If 4 GB stays free and it still dies on one file, it is that file or its cache entry.

How to confirm it is actually fixed

Run the same import twice and check three things:

• free -h still shows 1 GB or more available at the peak, and swapon --show lists your swapfile.
• journalctl -b -0 | grep -i oom shows no new kill for Godot_editor after the test.
• The editor opens the project twice in a row without reimporting everything, and .godot/imported timestamps stop changing.

If the second open is fast and the OOM log is quiet, the freeze is fixed. If it still names one texture in godot.log, keep that file out of res://, re-export it at half resolution, and import it alone. One repeatable file means one bad asset, not one bad system.