Linux GLCore Graphical Issues / Vulkan Memory Leak

To help narrow down the cause of the ongoing memory growth, I’ve gathered heap-allocation data using jemalloc’s built-in profiler.

I launched the game with:
Code: 
LD_PRELOAD=/usr/lib/libjemalloc.so.2 \
MALLOC_CONF='prof:true,prof_prefix:/tmp/jemalloc.7d2d,lg_prof_interval:24,lg_prof_sample:16' \
%command% -skipnewsscreen=true -skipintro -force-vulkan

After exiting the game, I generated a textual allocation summary with::
Bash: 
jeprof --text /usr/lib/libjemalloc.so.2 /tmp/jemalloc.7d2d.* > jeprof.txt

And captured the module map for symbol resolution:
Code: 
PID=$(pgrep -n 7DaysToDie)
cat /proc/$PID/maps > maps_at_profile.txt

Attached files:
  • jeprof.txt - heap allocation summary
  • jemalloc.7d2d.21678.heap.zip - raw profiling data for analysis
  • maps_at_profile.txt.zip - module map from the same session

Hopefully this helps track down the leak source in case devs don't have Linux machines to reproduce with.
 

Attachments

I did some additional testing underneath Linux Mint 22.2.
It resulted in the same issues however I still wanted to provide a video, configs and log file.

Video:

/etc/security/limits.conf: https://pastebin.com/6ujePk3P
I noticed that the /etc/security/limits.conf file is pretty much useless and doesn't work.
I needed to change the limits inside of the systemd files below to actually apply. I still changed it just to be sure and wanted to include it for completeness.
/etc/systemd/user.conf: https://pastebin.com/QCmV60jk
/etc/systemd/system.conf: https://pastebin.com/T9yAfa8E

Logfile: https://justpaste.it/b17ry
I was unable to upload the entire file because the following lines were spammed across the whole log making it impossible to upload:
- Vulkan - Suboptimal memory type used for buffer because of low memory
- Vulkan - Suboptimal memory type used for image because of low memory
I used uniq to get rid of duplicate lines after which I was able to upload it.

Unrelated to all that.
I wanted to throw into the conversation that I tried replacing the mono runtime with the latest one available on gitlab.
It didn't solved the issue however the reported file limit in the log was different, from 1624 to 1724. It is still no where near what the actual file limit is, but still interesting to see.
 
Last edited:
Hello! Just checking in after multiple months to "bump" the bug report - have there been any recent developments on the issue?

I can personally confirm that all the aforementioned issues with VRAM memory leaks on Vulkan are the exact same as they used to be, while the default GLcore causes terrible performance when having SSAO turned on, or, even worse, damaging zombies with anything else than fists causes an extremely uncomfortable, bright flashing light effect to blast in your eyes, rendering the game close to unplayable.

Of course we'd all be happy to have these issues resolved eventually (rather as quickly as possible), but I can suggest the simplest, fastest one that can at least make the game playable again (in terms of multiplayer servers).

Currently if a server is protected by EAC it must be accessed through the native Linux port of the game, otherwise (using any Steam Proton versions) EAC will throw an error about file integrity failure caused by an unknown file (ntdll.dll). All that needs to be done, is to enable a toggle for EAC compatibility with Steam Proton which Steam already provides for other EAC-protected titles!

Excited to get back into the game again after a while, and would love these important issues to be resolved ASAP!
 
You must log in or register to reply here.
Back
Top