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].
To view this discussion on the web visit 
https://groups.google.com/d/msgid/turbovnc-users/8c71eefc-d3a5-d8b4-c9c7-af9fa270e80f%40virtualgl.org.
For more options, visit https://groups.google.com/d/optout.

Reply via email to