It's unclear why this option would be necessary, and it causes problems
when people do not match it to their toolchain and CFLAGS.
To set the float abi, either use a toolchain with an appropriate default
or set the float-abi option in the CFLAGS environment variable.
This should resolve#2586.
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
When a hdc is created no initial or default objects are created
therefore can the first call of gdi_SelectObject return NULL.
Because of this checking the return value of gdi_SelectObject failed
for newly create hdc causing errors (disconnects).
Since all types of HGDIOBJECT are handled and the return value of
gdi_SelectObject isn't used the recently added checks were removed
again.
rfx_process_message_sync:
- simplified the check if the header messages got processed
rfx_process_message_tileset:
- ObjectPool_Take result was not checked
- fail if TS_RFX_TILE block type is not CBT_TILE
- CreateThreadpoolWork result was not checked
- post decoding loop code segfaulted in error case
rfx_decoder_tile_new:
- missing malloc check
rfx_message_free:
- segfault protection
rfx_write_message_tileset:
- segfault protection
- removed some unneeded null checks for free()
- fixed a memory leak in shadow_client
- removed rfx_compose_message_header from API
Changed the following functions to BOOL, check the result
where they are called and handle failures:
- rfx_compose_message
- rfx_compose_message_header
- rfx_write_tile
- rfx_write_message_tileset
- rfx_write_message_frame_begin
- rfx_write_message_region
- rfx_write_message_frame_end
- rfx_write_message
rfx_process_message:
- check memory allocation failures
- verify protocol-conform order of data messages to prevents memory
leaks caused by repeated allocations
- verify that header messages were parsed/received before the
data messages
- treat unknown rlgr mode as error
- fixed/added error handling
- fixed all callers to check/handle result
rfx_encode_message:
- fixed incorrect usage of realloc
- missing malloc check
- missing check of CreateThreadpoolWork
- correct cleanup on failure (threadpool, memory)
- check rfx_encode_message result
rfx_encode_messages:
- check rfx_split_message result
- correct cleanup on failure
- prevent memory leak on failure
rfx_write_message_context:
- fixed invalid channelId value (must be 0xFF for WBT_CONTEXT)
rfx_process_message_codec_versions:
- fixed invalid read size of codec_version (it is 16bit)
rfx_process_message_channels:
- verify protocol conform channelId value
rfx_process_message_region:
- replaced invalid reallocs with malloc
- read and verify regionType and numTileSets from stream
rfx_process_message_tileset:
- check allocation results
- fixed incorrect usages of realloc
setupWorkers:
- fixed incorrect usages of realloc
rfx_split_message:
- removed dead code
- missing malloc check
rfx_compose_message:
- fixed a memory leak
- check/handle rfx_encode_message result
* top level GDI functions return 0 on error and != 0 otherwise but the
low level functions (16bpp.c, 8bpp.c 32bpp.c) which are called did it
exactly the other way around. Those were adapted.
* change gdi_InvalidateRegion to BOOL and check calls where appropriate
* integrate comments from pull request
Now using nCount as in and out argument.
When called, set nCount to the number of available handles.
This value is checked and an error returned, if not enough
handles are available.
* Though not frequent, it's possible to get TsProxySetupReceivePipe
data of stublength 4 that is actual data. This happens when
header->common.call_id == rpc->PipeCallId &&
!(header->common.pfc_flags & PFC_LAST_FRAG).
This should address GW disconnects that manifest as SSL read errors.
