49d9e61884
When uploading large ICON (96x96), we end up growing the stream mid-update. Stream_EnsureCapacity end up reallocating the stream with a larger capacity to accomodate the large ICON size, but in doing so, also updating the sealed length for the data currently in the stream. This breaks the assumption between update_begin_paint and update_end_paint where the sealed lenght is used to keep track of the location where we need to update the orders counts after we're done accumulating update. As a result of the growth and lost of that location, the number of orders is written to the wrong location and the resulting stream is invalid which result in a protocol violation and a connection drop. The current fix uses a new offsetOrder in the update object to keep track of where update_end_paint needs to write the number of orders contained. I think a better fix would be for Stream_EnsureCapacity to preserve the sealead length of the stream on growth, but this has a much more significant impact and careful analysis needs to be done to ensure this doesn't violate other assumption. Need to follow up with FreeRDP developer to get their take on this one. |
||
|---|---|---|
| .. | ||
| cache | ||
| codec | ||
| common | ||
| core | ||
| crypto | ||
| gdi | ||
| locale | ||
| primitives | ||
| utils | ||
| CMakeLists.txt | ||
| freerdp.pc.in | ||
| FreeRDPConfig.cmake.in | ||