0
Planned

Guest client memory leak in (x)ubuntu-16.04.3-desktop-amd64

kadler 2 years ago updated by Ben Burner 2 years ago 10

I've built and installed a ConnectWiseControl.ClientSetup.deb package on a test system and a few VirtualBox VMs that are running Xubuntu 16.04.3 desktop (official Ubuntu but with Xfce desktop environment). I've also tested with regular Ubuntu and I see the same issue.


The guests show up in my machines list without any problem, but when I monitor memory usage with htop, I see that the java ScreenConnect.Client.Jar process balloons its memory usage until the system begins swapping and eventually becomes unusable.


I can reproduce on multiple systems by pulling up htop, sorting by MEM%, connecting a ScreenConnect session to the guest, and watching while the memory grows uncontrollably.



ConnectWise Control Version:
19.0
Server Affected:
Host Client Affected:
Guest Client Affected:
Waiting for information

Good morning,


Thank you for reporting this behavior. I am in the process of attempting to reproduce what you've described.


Can you please update this thread with the active version of Java on the xubuntu guest? Also, about how long were you connected to the guest via Control for the memory consumption to reach 74%?


Regards,

Ben

Hi Ben,


Kris is out for a week so I'll supply some information. Running `java -version` on the system produces the following output:


openjdk version "1.8.0_151"

OpenJDK Runtime Environment (build 1.8.0_151-8u151-b12-0ubuntu0.16.04.2-b12)

OpenJDK 64-Bit Server VM (build 25.151-b12, mixed mode)

Regarding the amount of time until memory reaches 74%, I believe it was around a day. Memory growth becomes apparent relatively quickly though (within hours). 


I will monitor the host during the course of the day to see what I come up with.

Hi Erem,


I was able to reproduce the behavior described in this thread on an XUBUNTU vm; however, the client's memory consumption increased using either openjdk-9 or Oracle Java9 only.


When I made openjdk8u151 the active runtime, the client's memory footprint did not expand throughout the duration of the active connection.


I'm wondering if you can reproduce similar behavior by upgrading one of your guest machines to openjdk-9 and retesting? You can push a reinstall to the client after upgrading Java so that the client picks up on the newer jvm.


In any case, I've registered an issue with development, and it's currently under investigation.


Cheers,

Ben

Hi Ben,


I don't want to upgrade to jdk9 because of other programs running on the box in question. But running on the version I posted last time, the memory has already grown from 3% to 8% over the last 1.5hours or so.

Usage is now at 10.5%

Now at 15.4. Looks like usage grows by about 5% per hour.

Hey Ben, have you had any more time to investigate this issue?

Planned

Good afternoon Erem,


The development team is continuing to investigate this behavior.


I appreciate the information you've provided, and I will update this thread once we know more about what's causing the growth in memory consumption.


Regards,

Ben

I have a bit more information. I've found that in Ubuntu / Xubuntu 16.04.3 LTS, that running


sudo apt-get install ./ConnectWiseControl.ClientSetup.deb


with the bundled installer created from my host access dashboard results in openjdk-9-jre being installed as a dependency. Basic features like send / receive file, right clicking on the ScreenConnect icon, are completely broken with Java 9. Lots of errors are written to /var/log/screenconnect-*.log. I'm sure the memory leaks are associated with these errors.


If the ScreenConnect client doesn't work with Java 9, that should be made clear, and the install package should not use Java 9.

Thank you for reporting this. I was able to replicate this behavior in our environment, and have registered an issue with development.


Regards,

Ben