Coverity has generated a number of 'Data race condition' and 'Double
lock' false positives. A lot of these seem to be caused by the NULL
guard in tc_mutex_unlock() not being paired with a NULL guard in
tc_mutex_lock(). This PR adds a NULL guard to tc_mutex_lock().
It should be noted, that on Linux at least, passing NULL to
tc_mutex_lock() causes a segfault. We clearly aren't doing this at the
moment, or we'd know about it. A log message is generated if a NULL
call is made, rather than failing silently.
This Coverity issue was encountered in a private build, but does not
appear to be in the Github CI build. Coverity is suspecting a copy-paste
betweem these lines in sound.c:-
1838: xstream_copyin(s, &g_stream_inp->data[g_stream_inp->size - g_bytes_in_stream], i);
1844: xstream_copyin(s, &g_stream_inp->data[g_stream_inp->size - g_bytes_in_stream], g_bytes_in_stream);
An inspection of the code shows this to bre a false positive
Coverity seems to have some problems with the loop(s) copying data from
one socket to another, in that it assume that eventually an integer
overflow will occur. It's not obvious why this should be flagged, but
this seems likely to be a false positive.
This commit avoids the integer issue by using a simple pointer + count
mechanism.
The socket copy code has been placed in a separate function - before it
was duplicated. Minor fixes have been made to error reporting around the
connection code.
We found during deployment that it is possible for some configurations
to have the build-time noopenh264 library installed, rather than the
openh264 library. This causes a failure which is difficult to diagnose.
The automated Coverity scan does not currently include neutrinordp
Two problems fixed:-
1) MAX_STATIC_CHANNELS at 31 is bigger than freerdp->sessings->channels
(16)
2) pamusername in the mod parameters is assumed to be 256 bytes when
it is written to.
xrdp_wm_clear_popup() clears down a popup window, but does not
clear the pointer. This can potentially lead to a double-free on
the popup window bitmap.
Operating System
Ubuntu
24.04.1
LTS
Runner Image
Image: ubuntu-24.04
Version: 20250105.1.0
Included Software: https://github.com/actions/runner-images/blob/ubuntu24/20250105.1/images/ubuntu/Ubuntu2404-Readme.md
Image Release: https://github.com/actions/runner-images/releases/tag/ubuntu24%2F20250105.1
Removing libibus-1.0-dev:i386 and libimlib2-dev:i386 from the 32-bit
build fixes this error:-
The following packages have unmet dependencies:
shim-signed : Depends: grub-efi-amd64-signed (>= 1.191~) but it is not going to be installed or
grub-efi-arm64-signed (>= 1.191~) but it is not installable or
base-files (< 12.3)
Depends: grub-efi-amd64-signed (>= 1.187.2~) but it is not going to be installed or
grub-efi-arm64-signed (>= 1.187.2~) but it is not installable
E: Error, pkgProblemResolver::Resolve generated breaks, this may be caused by held packages.
This is somewhat difficult to comprehend, as the following packages are
installed:-
base-files 13ubuntu10.1
grub-efi-amd64-signed 1.202+2.12-1ubuntu7
shim-signed 1.58+15.8-0ubuntu1
Add an option to allow XAUTHORITY to be moved away from $HOME.
This is modelled on the lightm 'user-authority-in-system-dir' option,
and also current GDM default behaviour.
The errors in sesman/chansrv/chansrv_fuse.c appear to be false positives
caused by allocating xhandle->dir_handle, and then
casting xhandle to an integer in xfuse_handle_to_fuse_handle(), thus
hiding xhandle->dir_handle
For both occurrences, the logic has been simplified and made the same,
and a comment has been added to suppress the error.
jsorg71