Massive initial memory usage and leak

[p4block]

Describe the bug
Opening the client. specially using network dependent features such as downloading stuff from the Vault or starting a simply hosting a co-op map will consume gigabytes upon gigabytes of RAM. (Around 4-6GB then 8 when launching the client)

Additionally, the ram usage of the client will slowly creep up until the system runs out of RAM regardless of what I do.

The console is surprisingly quiet about all of this. Some network errors pointing to unreachable URLs (that 404 if opened with the browser) happen from time to time.

To Reproduce
Install the client from the AUR, launched it, monitor RAM with your preferred method.

Expected behavior
RAM usage is not world ending.

OS
Arch Linux w/ mesa-git and linux 5.5, but has been happening for a log while.

[Katharsas]

Duplicate of #1534
Seems to me like the AUR package is the cause for this problem, because other people on Linux who do not ue Arch do not have this problem.

The AUR package is not created by FAF devs and not supported.
Maybe try the official releases: https://github.com/FAForever/downlords-faf-client/releases
You may get help setting that up here: http://forums.faforever.com/viewtopic.php?f=2&t=4507

[p4block]

The issue persists using the program directly downloaded from github.

Additionally, I'd like to add that the AUR package is well written a does a nice job of integrating it with the system, it doesn't do anything wrong.

I'd point my finger of blame to a forced unsupported-for-two-years version of the jvm doing weird stuff, but who knows really. Considering the ram usage doesn't even show as attached to the process, AND doesn't return when closed, something very bad is happening to the system.

[Katharsas]

Reopneing this instead of #1534
What unsupported JRE version do you mean? The current client should run fine on jre openjdk 11 (which is basically a current Java LTS).

[p4block]

I'm unable to run this without pointing it to openjdk10. Openjdk11 will trigger

No suitable Java Virtual Machine could be found on your system.
The version of the JVM must be 10

I glanced at the code and the build specifically targets 10 compatibility, not 11 or higher. (maybe they use a weird off by one internal api versioning or something, not really familiar with desktop jdk)

[1-alex98]

We can change this in the installer, it is miss set

[1-alex98]

changed it in the installer next version will allow u to use 11 12 and 13

[p4block]

I tested it with java 11 and the memory usage seemed better in the client, but catastrophically failed when I launched the game (faster than even the others), so that's a weird behavior.

JDK 13 still prompts the warning saying that my java version should be between 10 and 13.

This may have to do with java 13 using an internal version code of "HIGHER" and not 13. I guess they intend to stop people from targeting specific jdks.

Launching the client specifying jdk13 path on the appropriate environment variable forces it to launch, however, the client ui is completely broken on jdk13 and massive (and beautiful) stacktraces show up on the console.

[p4block]

So, after testing on my laptop and finding the issue wasn't happening there, a few hours of chatting and a long stack of happy coincidences, the issue has been narrowed down.

There's a bug somewhere in the javafx/xorg/mesa/llvm/drm/kernel (seen a lot of the Spiderman meme situation, with the everyone pointing at each other) that causes memory to not be freed after being allocated. It's innocuous in desktop usage as the memory leak is really slow.

It's likely that the hacked together progressbars in javafx are acting as a torture test and triggering the bug in extreme.

By searching for "javafx mesa linux memory leak" similar behavior is seen by people as far back as 2016.

There are two workarounds for the issue:

1. Disable DRI3. Seems to slow down or eliminate the memory leak, but another side-bug with cpu usage may still persist according to some reddit comments.

2. Run the ui in software rendering.

This, of course, nukes performance. But it's a 2d launcher, so...

Added to the downlords-faf-client.vmoptions file in the client folder the following line:

-Dprism.order=sw

This could be done automatically for linux builds, but that would hurt users that don't have the presumably very specific software/hardware combo required to trigger the bug.

[Katharsas]

Thanks for investigating. The progressbar has created quite some trouble so far (see #1371)

[1-alex98]

Well I close this because apparently there is nothing we can do