Hi, I did some more digging in the FreeRDP code and now I don't think there's a leak where I said earlier, the stream seem to be freed inside FreeRDP within the virtual channels infrastructure. So it must be somewhere else.
I ran valgrind and monitored guac while downloading two 100MB files. The output is attached, you can see in the bottom that there's a 200MB leak related to stream_new. Thanks, Gabriel On Tue, 10 Dec 2019 at 16:06, gabriel sztejnworcel <[email protected]> wrote: > Hi Mike, > > Thanks for your help and for all the hard work invested in this project :) > > I see the memory of guacd climb (not the main service, the child process > created for the session). I also see out of memory message in the log. > > I looked at the code and found some places that look suspicious, but I'm > not sure. For example, in guac_rdpdr_fs_process_write I see a call to > guac_rdpdr_new_io_completion which creates a new stream and sends it over > the virtual channel, but I don't see that the stream if freed. I tried to > free the stream after svc_plugin_send but it caused the process to crash > immediately, looks like svc_plugin_send is async, so in order to free it > properly we need to use some FreeRDP callback. > > But I might be misinterpreting it and the stream is free somewhere else > and that's not really the issue. I've tried to run valgrind but I can't get > it to work. What do you think? > > Thanks, > Gabriel > > On Tue, 10 Dec 2019 at 00:47, Mike Jumper <[email protected]> > wrote: > >> On Mon, Dec 9, 2019 at 3:36 AM gabriel sztejnworcel < >> [email protected]> wrote: >> >>> Hi, >>> >>> We are using Guacamole 1.0.0. >>> >>> When downloading large files using Guacamole's RDP drive redirection, at >>> some point (after transferring around 3GB) the process reaches it's memory >>> limit and stops. It happens also when transferring smaller files one after >>> the other, it seems like the memory is not released even after the file >>> transfer is completed. >>> >>> Has anyone encountered this issue? Is there an open bug for this? >>> >> >> There is one issue affecting 1.0.0 and older which would prevent >> successful transfer of files once ~4 GB is reached. This is due to >> incorrect usage of a 32-bit value to represent file seek offsets: >> >> https://issues.apache.org/jira/browse/GUACAMOLE-764 >> >> There are no known issues with file transfer, fixed or otherwise, which >> would result in server memory usage increasing until some process limit is >> reached. Are you seeing the actual memory usage of the guacd process climb? >> Or are you just seeing transfer appear to stop? >> >> - Mike >> >>
valgrind.log
Description: Binary data
--------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
