Memory Leak in Goto Renderer and 7 Hour Timeout

[ShadowPeak]

Awhile back I made this post about the GoTo software kicking me out after about 7 hours:  7 Hour Timeout for Session Host.  I was directed to open a case and it was confirmed there is no meeting timeout.  Swell.

I do system and network performance analysis for a living, so I looked into the issue professionally.  There is a confirmed memory leak in the GoTo.exe renderer process that consumes an astonishing 400-400MB per hour on the session host system without free'ing it back .  After about 7 hours when it reaches a ridiculous 3.8GB of memory utilization the process crashes due to lack of memory, thus kicking me out of the meeting with no error message at all or prompt to select a new organizer/presenter.  3.8 GB is suspiciously close to the 4GB 32-bit memory limit, which would appear to indicate there are 32-bit elements inside this process even though it is running in 64-bit mode on a 64-bit operating system; doing so does not magically make everything in that binary 64-bit capable.  I have confirmed this memory leak on a Windows 7 64-bit Lenovo W520 and a Windows 10 64-bit Lenovo P52.  The evidence screenshots show the renderer process memory utilization at startup  (250MB which is reasonable), after 3 hours (1.8GB which is not reasonable), and after 7 hours (an insane 3.7GB right before it dies, with extra info shown):

Both systems are Lenovo so it is possible that some Lenovo-specific driver may be causing this.  I have saved a minidump and fulldump of the memory-leaking process when it was at about 3.6GB allocated that I can provide.  No, turning on efficiency mode does not solve the problem.  Yes, I am running the latest version of the GoTo software 0.112.14. 

So now that we have established the problem, here is what I'd like to see happen:

1) Refer this to someone who actually understands what has been written here.  I am not interested in opening a case and going through 8 levels of escalation and being told to upgrade my RAM (nope wrong, 19GB RAM free in the OS at time of crash, this is a process 32-bit limit thing)

2) Refer this to someone that can receive and actually understand the dumps I've taken.  It shouldn't be too difficult to see where all the memory is being leaked with the full dump I have.

Thanks!

[ShadowPeak]

I didn't say I was removed from the meeting, I said my meeting interface suddenly closes with no input from me.  When I restart the software and reconnect to the meeting all attendees are still there and I see two of myself.  One is greyed out (which I excuse) and the other one was created when I reconnect.  The meeting software just closes with no message indicating what happened at all, sometimes when I am in the middle of talking and sharing.  Would be nice to have some diagnostics explaining what is happening instead of just closing itself, looks to be a client software issue.  Internet connectivity is solid, I'm on it constantly 10 hours a day and it never blips.

[KateG]

@ShadowPeak thanks for the clarification. You can report these instances when they occur by following the instructions in Glenn's post here. This will help our team review specific technical issues. 

[GoToMathias]

Hi ShadowPeak,

Thank you for this detailed post! I'm an engineering manager here at GoTo and we do look into post here in this community. I agree with your assessment: it does sound like the 4GB limit. This is a very good observation and the best we can hope for as a bug report. We are looking into issues like this and performance in general. Do you have an option to upload those dumps somewhere? They might be useful. We'll try to reproduce your observation in the meantime.

Can you tell us more details about the session? You wrote it has been running 7 hours+. Was that indeed GoToTraining? And which features did you use? Webcam, ScreenSharing, Breakout Rooms, Recording, Drawing Tools or Remote Keyboard and Mouse Control (Control Sharing)? 

[ShadowPeak]

Yes my sessions run about 8 hours using GotoTraining.  Only features used are me continuously sharing a screen and me on audio with occasional audio from about 8 attendees.  No cams at all, no screen sharing/control from attendees, no breakout rooms, no recording.  For drawing I only use the SysTools Zoomit suite but very intermittently.  I was watching the renderer memory utilization yesterday and the leakage seems to slow down quite a bit when my screen is paused but still shared; by keeping the screen paused most of the day whenever possible I was able to get through the 8 hour session without running the renderer out of memory.  Will look today and see if leakage still happens when no screen is shared.  

Please contact me on my email address associated with this account and if you can provide some kind of dropbox or SCP server I can upload the dumps.  Thanks!

[GoToMathias]

Thanks for these details! I'll note them down in a ticket but I do not yet know when we'll get to it.

[KateG]

@ShadowPeak I sent you a PM with an email on where to send the data. 

[GoToMathias]

Hi @ShadowPeak ,

we are still looking into this issue but we have not yet been able to identify a root cause. In the meantime, it looks like the browser version of the app does not suffer from this issue. Maybe this could be a workaround for you. Please let us know if the leak does not occur for you in the browser, if you give it a try.

Regards,

-Mathias