Memory Leak in Goto Renderer and 7 Hour Timeout
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!