Hi DRC, I've found a way to reproduce the memory leak now:
1. I start from scratch restarting the Xvnc session 2. then I start starccm+, load a simulation file and run it for some iterations 3. I stop the simulation, close the simulation BUT LEAVE starccm+ OPEN, without any loaded simulation file 4. I monitor the Xvnc memory usage with "ps u `pidof` and can see that the virtual memory size starts increasing about 10 secs after having closed the simulation, and doesn't seem to stop as long as starccm+ is open (without any file loaded) Does that help anyhow? Very strange behaviour. I will try with other StarCCM+ versions. Thanks, Richard On Mon, 8 Jul 2019 at 17:44, DRC <[email protected]> wrote: > OK, thanks. You might get some traction by building Xvnc using clang's > AddressSanitizer and LeakSanitizer. Without a specific procedure to > reproduce the problem, there is unfortunately little I can do. What I will > do, however, is double check the X.org commit log and see if there are any > leak-related patches that I need to back-port into the TurboVNC Server. > > libjpeg-turbo-official has never been necessary for our run-time > packages. It is only necessary when building VirtualGL or TurboVNC. > > On 7/8/19 3:24 PM, Richard Ems wrote: > > Hi DRC, > > thanks for your answer. > > Good to know installing libjpeg-turbo-official is not needed. I removed it > now. I think it was needed some time ago, or not? > > Yes, this is reproducible with TurboVNC 2.2.1. We were seeing the high > memory usage on TurboVNC 2.2.1 and that's why I updated to 2.2.2 hoping the > issue would go away. But the issue seems to be the same on both versions, > 2.2.1 and 2.2.2. > > And no, I am not sure it can only be reproduced with StarCCM+ (yes, right > "guess" ;-) ) . I did not try to reproduce it with other software. I even > couldn't reproduce it with StarCCM+, but not sure what users do over the > days to end up with this high mem usage. > > Thanks for the explanations and for looking into it. > > Cheers, > Richard > > > On Mon, 8 Jul 2019 at 17:01, DRC <[email protected]> wrote: > >> Unsure what is going on. What I can tell you is that: >> >> - Yes, that memory usage is too high. >> >> - The problem is with TurboVNC, not VirtualGL. If it were a leak in >> VirtualGL, then the memory usage would rise in the 3D application process, >> not in the Xvnc process. The memory leaks that I fixed in VirtualGL 2.6.2 >> truly were minor-- like so minor that they would have gone unnoticed unless >> you ran VirtualGL through valgrind (which is how I detected them.) The >> leaks mostly took the form of memory that was not properly freed at >> shutdown, so for the most part, they didn't grow the memory usage of >> VirtualGL while the 3D application was running. I fixed them primarily to >> make it easier to detect more serious leaks, if they are introduced in the >> future. >> Note that, if you are using the official VirtualGL and TurboVNC packages, >> those packages statically link with a specific version of libjpeg-turbo, so >> installing libjpeg-turbo-official is unnecessary, and the installed version >> of that package is not relevant for diagnostic purposes. >> >> I checked the diff between TurboVNC 2.2.1 and 2.2.2 and didn't see any >> obvious areas of concern. Some follow-up questions: >> >> - Are you sure that this isn't reproducible with TurboVNC 2.2.1? >> >> - Are you sure that it can only be reproduced with one specific 3D >> application? (StarCCM+, I'm guessing?) >> >> DRC >> >> On 7/5/19 9:36 AM, Richard Ems wrote: >> >> Hi all, hi DRC, >> >> DRC, thanks for your great work! TurboVNC + VirtualGL + libjpeg-turbo >> work great! >> >> But now we are seeing what looks like a memory leak in Xvnc. >> On a RHEL7.6 Workstation, we were using turbovnc-2.2.1, VirtualGL-2.6.1 >> and libjpeg-turbo-official-2.0.2 up to one week ago. >> We were seeing Xvnc consuming lots of memory, so I checked and found >> "Fixed several minor memory leaks in the VirtualGL Faker." in the >> "Significant changes relative to 2.6.1" list for VirtualGL-2.6.2 . >> So I upgraded TurboVNC from 2.2.1 to 2.2.2 and VirtualGL from 2.6.1 to >> 2.6.2 and restarted all VNC sessions. >> >> The memory usage for Xvnc was low for some days, but now after one week >> running, one of the VNC sessions shows in "top" 601.4g virtual memory and >> 127.9g resident memory in use. >> That seems to be to much, or not? >> >> In /etc/turbovncserver.conf I've set "$useVGL = 1;" , may this be an >> issue? This setting has been there for months and we were not seeing this >> issue before. >> >> The Xvnc command line showed by "ps" is: >> >> # ps uw 364412 >> USER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND >> <USER> 364412 1.1 25.4 632004096 134290304 ? Sl Jun27 133:52 >> /opt/TurboVNC/bin/Xvnc :20 -desktop TurboVNC: serv1.bartech.local:20 >> (<USER>) -httpd /opt/TurboVNC/bin//../j ava -auth /home/<USER>/.Xauthority >> -geometry 1240x900 -depth 24 -rfbwait 120000 -rfbauth >> /home/<USER>/.vnc/passwd -x509cert /home/<USER>/.vnc/x509_cert.pem -x509key >> /home/<USER>/.vnc/x509_private.pem -rfbport 5920 -fp >> catalogue:/etc/X11/fontpath.d -deferupdate 1 -dridir /usr/lib64/dri >> -registrydir /usr/lib64/xorg >> >> This user is continuously running an application that gets started with >> "-clientldpreload libvglfaker.so" . >> >> What is going on here? >> >> Kind regards, >> Richard Ems >> >> -- >> You received this message because you are subscribed to the Google Groups >> "TurboVNC User Discussion/Support" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to [email protected]. >> To view this discussion on the web visit >> https://groups.google.com/d/msgid/turbovnc-users/4b34a770-8cd1-42a0-ac55-a9cf492066ca%40googlegroups.com >> <https://groups.google.com/d/msgid/turbovnc-users/4b34a770-8cd1-42a0-ac55-a9cf492066ca%40googlegroups.com?utm_medium=email&utm_source=footer> >> . >> For more options, visit https://groups.google.com/d/optout. >> >> >> -- >> You received this message because you are subscribed to the Google Groups >> "TurboVNC User Discussion/Support" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to [email protected]. >> To view this discussion on the web visit >> https://groups.google.com/d/msgid/turbovnc-users/3661f75c-8163-3a21-d43b-8cd69c6500d2%40virtualgl.org >> <https://groups.google.com/d/msgid/turbovnc-users/3661f75c-8163-3a21-d43b-8cd69c6500d2%40virtualgl.org?utm_medium=email&utm_source=footer> >> . >> For more options, visit https://groups.google.com/d/optout. >> > -- > You received this message because you are subscribed to the Google Groups > "TurboVNC User Discussion/Support" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > To view this discussion on the web visit > https://groups.google.com/d/msgid/turbovnc-users/CAEqczzz6Ki3JR3H9Kt3so7%2Bn9LGN1-nwZt7M%3D32a4tuXyhP3aw%40mail.gmail.com > <https://groups.google.com/d/msgid/turbovnc-users/CAEqczzz6Ki3JR3H9Kt3so7%2Bn9LGN1-nwZt7M%3D32a4tuXyhP3aw%40mail.gmail.com?utm_medium=email&utm_source=footer> > . > For more options, visit https://groups.google.com/d/optout. > > > -- > You received this message because you are subscribed to the Google Groups > "TurboVNC User Discussion/Support" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > To view this discussion on the web visit > https://groups.google.com/d/msgid/turbovnc-users/8c71eefc-d3a5-d8b4-c9c7-af9fa270e80f%40virtualgl.org > <https://groups.google.com/d/msgid/turbovnc-users/8c71eefc-d3a5-d8b4-c9c7-af9fa270e80f%40virtualgl.org?utm_medium=email&utm_source=footer> > . > For more options, visit https://groups.google.com/d/optout. > -- You received this message because you are subscribed to the Google Groups "TurboVNC User Discussion/Support" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/turbovnc-users/CAEqczzyr3T9w%2B%2BLO7epLSkTdK4zcuX%2B_3nO%3D2%2B%3Dok9OsVZZaTQ%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
