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:
Back
Top