Hi DRC, I started Xvnc with valgrind --leak-check=full , but got no error/leak messages from valgrind in the log file.
I then contacted the starccm+ support, and they asked me to try to reproduce using TightVNC, which I probably should have tried first. I then installed the tigervnc-server package from RHEL7 and started that vncserver. I cannot reproduce the memory leak anymore on this Xvnc version. So I am back to assuming that the issue is on the Xvnc version from TurboVNC :) What do you think? Any proposals on what I can do next? Many thanks, Richard On Tue, 9 Jul 2019 at 21:08, DRC <[email protected]> wrote: > Since you can reproduce the problem, I would recommend running the Xvnc > process with 'valgrind --leak-check=full' (the easiest way to do that is to > modify /opt/TurboVNC/bin/vncserver.) That should detect whether there are > any leaks in Xvnc. Your description suggests strongly that the issue is > with StarCCM+, and if it goes away when that application is closed, then > that would suggest more strongly that the application is to blame. If it > appears that valgrind is detecting something, then send me the output. > > DRC > > On 7/9/19 6:24 PM, Richard Ems wrote: > > 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 > <https://groups.google.com/d/msgid/turbovnc-users/CAEqczzyr3T9w%2B%2BLO7epLSkTdK4zcuX%2B_3nO%3D2%2B%3Dok9OsVZZaTQ%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/4729b454-3ed1-d297-e6f5-2f6556a410da%40virtualgl.org > <https://groups.google.com/d/msgid/turbovnc-users/4729b454-3ed1-d297-e6f5-2f6556a410da%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/CAEqczzzUhJs7PLd0pdBY%3Dy6jxgKK8bSsd1si3G5tywV9DiGpng%40mail.gmail.com.
