When the event is reset in transport_check_fds xfreerdp doesn't work and
consumes 100% CPU (see #2790). On windows this is require otherwise the
CPU consumption is 100% there.
This quick fix only resets the event on windows. It's a working approach
but definitely not the final solution.
- handle WAIT_TIMEOUT result as error in async transport thread
if an INFINITE timeout was specified in WaitForMultipleObjects
- fix mfreerdp's async transport handling to not use
freerdp_get_event_handles/freerdp_check_event_handles if async
transport is activated
1)
Added missing checks for CreateEvent which also required the
following related changes:
- changed freerdp_context_new API to BOOL
- changed freerdp_peer_context_new API to BOOL
- changed pRdpClientNew callback to BOOL
- changed pContextNew callback to BOOL
- changed psPeerAccepted callback to BOOL
- changed psPeerContextNew callback to BOOL
2)
Fixed lots of missing alloc and error checks in the
changed code's neighbourhood.
3)
Check freerdp_client_codecs_prepare result to avoid segfaults
caused by using non-initialized codecs.
4)
Fixed deadlocks in x11 caused by missing xf_unlock_x11() calls
in some error handlers
5)
Some fixes in thread pool:
- DEFAULT_POOL assignment did not match TP_POOL definition
- don't free the pool pointer if it points to the static DEFAULT_POOL
- added error handling and cleanup in InitializeThreadpool
Change the return type of Stream_Ensure*Capacity from void to BOOL to be
able to detect realloc problems easily. Otherwise the only way to detect
this was to check if the capacity after the call was >= the required
size.
In case Stream_Ensure*Capacity fails the old memory is still available
and need to freed outside.
This commit also adds checks to most calls of Stream_Ensure*Capacity to
check if the call was successful.
Situation: we have fragmented TPKT PDU without two last bytes
(or one last byte - for fast-path) in network stack.
First call to transport_read_pdu() works normally, read
available bytes and exit with status 0 - no whole PDU readed.
Before second call this missed bytes arrive.
Optionally with next PDU.
In second call header parsing code unconditionally read this
two bytes(one byte) despite this is not header bytes.
And increase stream position, so stream now contains whole PDU.
This cause (pduLength - Stream_GetPosition(s)) calculation to be 0.
So transport_read_layer_bytes()-->transport_read_layer() return 0
and transport_read_pdu() exits with "not enough data is available"
status.
If next PDU isn't available next calls to transport_read_pdu()
give same result.
If next PDU arrive - (pduLength - Stream_GetPosition(s)) will be
less than 0. Stream position will grow, grow and grow on each call.
And transport_read_pdu() never signals that PDU is readed.
Caught on Android FreeRDP client with high RDP traffic (several MBytes/s).
