Dust3D 1.1.3 AppImage causes massive memory allocation and OOM on Intel HD 4400 (Qt6/X11/Linux)

[MiqueiasDevGames]

System:

• antiX / Debian Trixie
• Kernel: XanMod
• X11 + XFCE
• Intel HD Graphics 4400 (Haswell GT2)
• Mesa 25.0.7
• OpenGL 4.6
• Driver: crocus
• direct rendering: Yes

GPU info:
OpenGL renderer string: Mesa Intel(R) HD Graphics 4400 (HSW GT2)
OpenGL version string: 4.6 (Compatibility Profile) Mesa 25.0.7-2

Problem:
The Dust3D 1.1.3 AppImage instantly triggers extremely large memory allocations and gets killed by the Linux OOM killer during startup.

The application never fully opens.
Depending on environment variables, I get:

• immediate process kill
• transparent window
• black window
• or OOM kill

Kernel logs show Dust3D allocating absurd amounts of virtual memory (25–33 GB VM) and around 5 GB RSS before being terminated.

dmesg:
Out of memory: Killed process (AppRun)
total-vm: 25063256kB
anon-rss: 4816420kB

Important:
The system OpenGL stack itself appears healthy:

• glxinfo works correctly
• glxgears works correctly
• OpenGL acceleration is active
• renderer is proper Intel hardware acceleration (not llvmpipe)

I tested many combinations:

• crocus
• i965
• software backend
• xcb_glx
• xcb_egl
• DRI3 disabled
• compositor disabled
• Qt software rendering

The only partial result was:
QSG_RHI_BACKEND=software
which opened a transparent/black window instead of crashing immediately.

This suggests the issue may be related to:

• Qt6 SceneGraph
• RHI backend
• AppImage bundled Qt runtime
• excessive framebuffer allocation
• or GPU backend initialization on older Intel Haswell GPUs.

It may also indicate a Qt6 + Mesa + Haswell compatibility issue specific to the AppImage runtime.

Older Dust3D versions may behave differently, but 1.1.3 AppImage is currently unusable on this hardware.

[huxingyi]

Hi @MiqueiasDevGames, thanks for the detailed report! Could you run the attached collect_oom_report.sh script on your machine?

collect_oom_report.sh

chmod +x collect_oom_report.sh
./collect_oom_report.sh

It will download the 1.1.3 AppImage automatically, run for about 3 minutes, and produce a file named dust3d_oom_report_<hostname>_<date>.txt.

What the report contains:

• Kernel version, CPU info, total RAM
• glxinfo output (GPU renderer, Mesa version, OpenGL extensions)
• Installed Qt/Mesa package versions
• Peak RSS and VM for each of 5 test runs (opengl / software / qt-software-gl / llvmpipe / vulkan)
• Full app log per test (Qt plugin loading, RHI init messages, any errors)
• dmesg OOM events if any

Please review the file before uploading — glxinfo output includes your hostname and username. Open it in a text editor and redact anything you're not comfortable sharing, then attach it here.

Requirements: wget, glxinfo (sudo apt install mesa-utils). Run from your normal X11 desktop session, not over SSH without display forwarding.

[MiqueiasDevGames]

Good morning! Here it is: dust3d_oom_report_msq_20260601_110458.txt

[huxingyi]

Hi @MiqueiasDevGames, can you help to download this appimage and try: https://dust3d.org/download/dust3d-latest-preview.AppImage

[MiqueiasDevGames]

The same problem, the application crashed because it ran out of memory. According to the dmesg logs, the Dust3D process (AppRun) was terminated by the Linux kernel's Out of Memory (OOM) killer. During execution, the software attempted to allocate over 14 GB of virtual memory and was actively consuming around 4 GB of physical RAM, which exceeded the system's available memory limits and triggered the forced shutdown. I have 8GB of RAM, zram enabled at 4GB, and swap configured, but either way, this is an issue with Dust3D.

[huxingyi]

Thanks @MiqueiasDevGames, originally I thought it was missing library or packed incorrect driver files. I did further test, it needs at least 4G memory (dedicated to this software) for the version 1.1.3. When software started, it needs to prepare the resource for the welcome scene, which includes a minimal demo playground. Will looking into the future to optimise that memory consumption and will let you know once I have an update.

[MiqueiasDevGames]

Thank you! I have 8GB of RAM! I even enabled ZRAM and swap.
The app opens, I upload two images (front and back), I manage to make three circles, and then it closes.
However, if I wait on the first screen for the same amount of time, it also closes and dies.

[rilex037]

I have a 32 gigs of ram, running app image instantly chokes and hogs every single bit of memory + page file and freezes whole pc

[didli]

Same behavior with appimage version 1.1.6 on an archlinux VM (xfce, 12 GB RAM). As soon as the apps open, it freezes instantly and I can't do anything until it is oom killed.

dust3d_oom_report_gfx-obs-dev-arc_20260718_085202.txt

[Saber-1980]

I'm having the same problem on Kubuntu 26.04: within 4 seconds, the AppImage allocates the entire 64 GB of RAM, the system freezes until OOM kicks in and kills the process.

dust3d_oom_report-desktop_20260723_202501.txt

[Tiag0ss]

Same issue with version 1.1.6 this just blow my RAM in 1m after start the appimage

[horenso]

Hi I just wanted to say I also tried the AppImage on Linux Mint 22.3 x86_64 and I see the same behavior. It shuts down after a few seconds because it allocates my entire 14Gib (The OS and other programs combined take about 2 Gib) of free ram.

dust3d_oom_report_bigboi_20260815_152032.txt

I attached the report but it's quite similar to what we've already seen.