Hi, thanks for your reply! We are using FreeRDP 2.2.0. Meanwhile we have also seen the difference inside between this and 2.0.0, with FreeRDP 2.0.0 using Stream_Free to free a wStream while 2.2.0 uses a StreamPool and calls Stream_Release instead.
A slightly more in-depth overview of what we found so far to be the case with Guacamole server 1.2.0: As part of the file upload process, we call the function "guac_rdpdr_fs_process_read". In this function we allocate a wStream object using the function "guac_rdpdr_new_io_completion". This function uses "Stream_New" in order to allocate the stream. Stream_New creates a new stream object and allocates dedicated memory for it. Next, in the "guac_rdpdr_fs_process_read" function we call "guac_rdp_common_svc_write" function. This function receives the allocated stream, and passes it to a function called "pVirtualChannelWriteEx". This function has a comment attached to it mentioning that the wStream object will be automatically freed by FreeRDP using Stream_Free. As we understand, this freeing is supposed to happen in the "drdynvc_virtual_channel_open_event_ex" in FreeRDP. However, on May the Stream_Free was replaced by Stream_Release which expects a wStream received from a StreamPool, and tries to return it to the pool. If the wStream was not received from a pool (which is the case for Guacamole server), the Stream_Release function does nothing, and does not free the allocated memory of this stream. This causes a memory leak, where none of the memory allocated during the file uploading is freed. If we assume that the problem is that Guacamole server 1.2.0 is not yet adapted to these more recent changes in FreeRDP 2, could you suggest a way to work around it, or to make the necessary change in Guacamole? Also, would you recommend using FreeRDP 2.0.0 at this stage rather than FreeRDP 2.2.0? Thanks! Jonatan -- Sent from: http://apache-guacamole-general-user-mailing-list.2363388.n4.nabble.com/ --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
