So you reproduced the leak while valgrind was running? If so, then I don't understand why it didn't catch it. The only other idea I have is to try building Xvnc with LeakSanitizer (which is in clang) and see if it can catch the leak in real time.
If I can actually see the leak and find out where it is in the code, it's probably a one-line fix. But without the ability to reproduce it myself, I'm not sure what else to do. If you can provide remote access to a machine that reproduces the problem, as well as reliable reproduction steps, I'm happy to look into it. I will try building Xvnc with LSan on my end and see if I can spot any problems using some test programs. On 7/31/19 11:09 AM, Richard Ems wrote: > 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] > <mailto:[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] >> <mailto:[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] >>> <mailto:[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] >>>> <mailto:[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] >>> <mailto:[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] >>> <mailto:[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] >> <mailto:[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] >> <mailto:[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] > <mailto:[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] > <mailto:[email protected]>. > To view this discussion on the web visit > https://groups.google.com/d/msgid/turbovnc-users/CAEqczzzUhJs7PLd0pdBY%3Dy6jxgKK8bSsd1si3G5tywV9DiGpng%40mail.gmail.com > <https://groups.google.com/d/msgid/turbovnc-users/CAEqczzzUhJs7PLd0pdBY%3Dy6jxgKK8bSsd1si3G5tywV9DiGpng%40mail.gmail.com?utm_medium=email&utm_source=footer>. -- 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/062afffc-78df-dc0d-5921-724f309b11bd%40virtualgl.org.
