Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Launching Steam freezes my system because of fossilize_replay taking whole memory #242

Open
Animal-Machine opened this issue Apr 22, 2024 · 1 comment

Comments

@Animal-Machine
Copy link

System information

  • Steam installer version: 1.0.0.75 (I don't know for Steam client version but it's the current one)
  • Distribution: Debian 12 (bookworm)
  • Opted into Steam client beta?: No (opting in resolves the issue)
  • Have you checked for system updates?: Yes

Description of the issue

After I replaced my motherboard, CPU and RAM, launching Steam would freeze my computer within a minute.

It appeared that my 32 GB of RAM + 1 GB of swap were full. In fact, 5 process named fossilize_replay grew quickly until they filled my RAM. Their sizes were all equal.

I can avoid freezing my computer by killing the processes as soon as possible. Apparently they can pop again because once, I had to kill them twice. As Steam was still working, it allowed me to opt into beta, idea given by this salutary form prefilling, and this solved my issue. Only one of the five "fossilize_replay" grows, and it stops at 1.5 GB.

This started happening since I replaced 4 sticks of RAM (total of 12 GB) by only 1 stick. But I was already experiencing some lag with Steam client, so I suppose 1 module was entirely taken by that. Maybe a prerequisite to reproduce is to have only one module but I can't tell exactly.

@kisak-valve kisak-valve transferred this issue from ValveSoftware/steam-for-linux Apr 22, 2024
@kakra
Copy link
Contributor

kakra commented Apr 22, 2024

As Steam was still working, it allowed me to opt into beta, idea given by this salutary form prefilling, and this solved my issue.

This is interesting: so the beta does not have the problem?

BTW: If you look at top or htop, the process size is shared between all processes: RAM is only used once (at least fossilize is designed to do that). Also compare the shared memory size: Add that once, then add the difference per fossilize process to calculate the real usage. htop allows adding the PSS column, which does this for you (proportional set size).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants