Random crashes when running remote apps since upgrading to 3.9.0 (arch linux)

[fusion916]

I am running remote apps from a Windows Server 2022 install and before upgrading to 3.9.0 everything was working fine. Now when trying to launch remote apps, it randomly crashes. Here is an example command I am using to run a program:

xfreerdp3 /v: /u:administrator /p: /scale:140 /scale-desktop:125 /app:program:"||win32calc" /cert:ignore '/auth-pkg-list:!kerberos' /gfx:RFX:off /gfx:AVC444:off

Sometimes calculator opens, and sometimes xfreerdp crashes with this printing on the console:

[00:27:03:500] [21180:000052bd] [INFO][com.freerdp.client.x11] - [xf_setup_x11]: Enabling X11 debug mode.
[00:27:03:565] [21180:000052bd] [WARN][com.freerdp.core.connection] - [rdp_client_connect_auto_detect]: expected messageChannelId=1009, got 1003
[00:27:03:566] [21180:000052bd] [WARN][com.freerdp.core.license] - [license_read_binary_blob_data]: license binary blob::type BB_ERROR_BLOB, length=0, skipping.
[00:27:03:704] [21180:000052bd] [WARN][com.freerdp.core.connection] - [rdp_client_connect_auto_detect]: expected messageChannelId=1009, got 1003
[00:27:03:710] [21180:000052bd] [INFO][com.freerdp.gdi] - [gdi_init_ex]: Local framebuffer format PIXEL_FORMAT_BGRA32
[00:27:03:710] [21180:000052bd] [INFO][com.freerdp.gdi] - [gdi_init_ex]: Remote framebuffer format PIXEL_FORMAT_BGRA32
[00:27:03:724] [21180:000052bd] [INFO][com.freerdp.channels.rdpsnd.client] - [rdpsnd_load_device_plugin]: [static] Loaded fake backend for rdpsnd
[00:27:03:725] [21180:000052bd] [INFO][com.freerdp.channels.drdynvc.client] - [dvcman_load_addin]: Loading Dynamic Virtual Channel ainput
[00:27:03:725] [21180:000052bd] [INFO][com.freerdp.channels.drdynvc.client] - [dvcman_load_addin]: Loading Dynamic Virtual Channel rdpgfx
[00:27:03:725] [21180:000052bd] [INFO][com.freerdp.channels.drdynvc.client] - [dvcman_load_addin]: Loading Dynamic Virtual Channel rdpsnd
[00:27:04:964] [21180:000052bd] [WARN][com.freerdp.client.x11] - [xf_Pointer_get_window]: xf_Pointer: Invalid appWindow
[00:27:04:968] [21180:000052bd] [WARN][com.freerdp.client.x11] - [xf_Pointer_get_window]: xf_Pointer: Invalid appWindow
[00:27:04:968] [21180:000052bd] [WARN][com.freerdp.client.x11] - [xf_Pointer_Set]: handle=0
[00:27:04:988] [21180:000052bd] [WARN][com.freerdp.client.x11] - [xf_Pointer_get_window]: xf_Pointer: Invalid appWindow
[00:27:04:988] [21180:000052bd] [WARN][com.freerdp.client.x11] - [xf_Pointer_Set]: handle=0
[00:27:04:994] [21180:000052e5] [INFO][com.freerdp.channels.rdpsnd.client] - [rdpsnd_load_device_plugin]: [dynamic] Loaded fake backend for rdpsnd
[00:27:04:124] [21180:000052bd] [WARN][com.freerdp.client.x11] - [xf_Pointer_get_window]: xf_Pointer: Invalid appWindow
[00:27:04:445] [21180:000052e5] [INFO][com.freerdp.channels.rdpsnd.client] - [rdpsnd_load_device_plugin]: [dynamic] Loaded fake backend for rdpsnd
[00:27:04:505] [21180:000052bd] [WARN][com.freerdp.client.x11] - [xf_Pointer_get_window]: xf_Pointer: Invalid appWindow
[00:27:04:535] [21180:000052bd] [WARN][com.freerdp.client.x11] - [xf_Pointer_get_window]: xf_Pointer: Invalid appWindow
[00:27:04:535] [21180:000052bd] [WARN][com.freerdp.client.x11] - [xf_Pointer_Set]: handle=0
[00:27:04:710] [21180:000052e5] [FATAL][com.freerdp.winpr.assert] - [winpr_int_assert]: !overlapping(pDstData, nXDst, nYDst, nDstStep, FreeRDPGetBytesPerPixel(DstFormat), pSrcData, nXSrc, nYSrc, nSrcStep, FreeRDPGetBytesPerPixel(SrcFormat), nWidth, nHeight) [/usr/src/debug/freerdp/FreeRDP-3.9.0/libfreerdp/codec/color.c:freerdp_image_copy_no_overlap:1614]
[00:27:04:710] [21180:000052e5] [FATAL][com.freerdp.winpr.assert] - [winpr_log_backtrace_ex]: 0: dli_fname=/usr/lib/libwinpr3.so.3 [0x7c6813ae9000], dli_sname=winpr_backtrace [0x7c6813b31180]
[00:27:04:710] [21180:000052e5] [FATAL][com.freerdp.winpr.assert] - [winpr_log_backtrace_ex]: 1: dli_fname=/usr/lib/libwinpr3.so.3 [0x7c6813ae9000], dli_sname=winpr_log_backtrace_ex [0x7c6813b316d0]
[00:27:04:710] [21180:000052e5] [FATAL][com.freerdp.winpr.assert] - [winpr_log_backtrace_ex]: 2: dli_fname=/usr/lib/libfreerdp3.so.3 [0x7c6813c00000], dli_sname=(null) [(nil)]
[00:27:04:710] [21180:000052e5] [FATAL][com.freerdp.winpr.assert] - [winpr_log_backtrace_ex]: 3: dli_fname=/usr/lib/libfreerdp3.so.3 [0x7c6813c00000], dli_sname=freerdp_image_copy_no_overlap [0x7c6813d51250]
[00:27:04:710] [21180:000052e5] [FATAL][com.freerdp.winpr.assert] - [winpr_log_backtrace_ex]: 4: dli_fname=/usr/lib/libfreerdp3.so.3 [0x7c6813c00000], dli_sname=(null) [(nil)]
[00:27:04:710] [21180:000052e5] [FATAL][com.freerdp.winpr.assert] - [winpr_log_backtrace_ex]: 5: dli_fname=/usr/lib/libfreerdp-client3.so.3 [0x7c6813ecf000], dli_sname=(null) [(nil)]
[00:27:04:710] [21180:000052e5] [FATAL][com.freerdp.winpr.assert] - [winpr_log_backtrace_ex]: 6: dli_fname=/usr/lib/libfreerdp-client3.so.3 [0x7c6813ecf000], dli_sname=(null) [(nil)]
[00:27:04:710] [21180:000052e5] [FATAL][com.freerdp.winpr.assert] - [winpr_log_backtrace_ex]: 7: dli_fname=/usr/lib/libfreerdp-client3.so.3 [0x7c6813ecf000], dli_sname=(null) [(nil)]
[00:27:04:710] [21180:000052e5] [FATAL][com.freerdp.winpr.assert] - [winpr_log_backtrace_ex]: 8: dli_fname=/usr/lib/libfreerdp-client3.so.3 [0x7c6813ecf000], dli_sname=(null) [(nil)]
[00:27:04:710] [21180:000052e5] [FATAL][com.freerdp.winpr.assert] - [winpr_log_backtrace_ex]: 9: dli_fname=/usr/lib/libwinpr3.so.3 [0x7c6813ae9000], dli_sname=(null) [(nil)]
[00:27:04:710] [21180:000052e5] [FATAL][com.freerdp.winpr.assert] - [winpr_log_backtrace_ex]: 10: dli_fname=/usr/lib/libc.so.6 [0x7c68136c0000], dli_sname=(null) [(nil)]
[00:27:04:710] [21180:000052e5] [FATAL][com.freerdp.winpr.assert] - [winpr_log_backtrace_ex]: 11: dli_fname=/usr/lib/libc.so.6 [0x7c68136c0000], dli_sname=(null) [(nil)]
[00:27:04:710] [21180:000052e5] [FATAL][com.freerdp.winpr.assert] - [winpr_log_backtrace_ex]: 12: unresolvable, address=(nil)
[00:27:04:710] [21180:000052e5] [ERROR][com.freerdp.utils.signal] - [fatal_handler]: Caught signal 'Aborted' [6]
[00:27:04:710] [21180:000052e5] [ERROR][com.freerdp.utils.signal] - [winpr_log_backtrace_ex]: 0: dli_fname=/usr/lib/libwinpr3.so.3 [0x7c6813ae9000], dli_sname=winpr_backtrace [0x7c6813b31180]
[00:27:04:710] [21180:000052e5] [ERROR][com.freerdp.utils.signal] - [winpr_log_backtrace_ex]: 1: dli_fname=/usr/lib/libwinpr3.so.3 [0x7c6813ae9000], dli_sname=winpr_log_backtrace_ex [0x7c6813b316d0]
[00:27:04:710] [21180:000052e5] [ERROR][com.freerdp.utils.signal] - [winpr_log_backtrace_ex]: 2: dli_fname=/usr/lib/libfreerdp3.so.3 [0x7c6813c00000], dli_sname=(null) [(nil)]
[00:27:04:710] [21180:000052e5] [ERROR][com.freerdp.utils.signal] - [winpr_log_backtrace_ex]: 3: dli_fname=/usr/lib/libc.so.6 [0x7c68136c0000], dli_sname=(null) [(nil)]
[00:27:04:710] [21180:000052e5] [ERROR][com.freerdp.utils.signal] - [winpr_log_backtrace_ex]: 4: dli_fname=/usr/lib/libc.so.6 [0x7c68136c0000], dli_sname=(null) [(nil)]
[00:27:04:710] [21180:000052e5] [ERROR][com.freerdp.utils.signal] - [winpr_log_backtrace_ex]: 5: dli_fname=/usr/lib/libc.so.6 [0x7c68136c0000], dli_sname=gsignal [0x7c68136fd100]
[00:27:04:710] [21180:000052e5] [ERROR][com.freerdp.utils.signal] - [winpr_log_backtrace_ex]: 6: dli_fname=/usr/lib/libc.so.6 [0x7c68136c0000], dli_sname=abort [0x7c68136e43e4]
[00:27:04:710] [21180:000052e5] [ERROR][com.freerdp.utils.signal] - [winpr_log_backtrace_ex]: 7: dli_fname=/usr/lib/libfreerdp3.so.3 [0x7c6813c00000], dli_sname=(null) [(nil)]
[00:27:04:710] [21180:000052e5] [ERROR][com.freerdp.utils.signal] - [winpr_log_backtrace_ex]: 8: dli_fname=/usr/lib/libfreerdp3.so.3 [0x7c6813c00000], dli_sname=freerdp_image_copy_no_overlap [0x7c6813d51250]
[00:27:04:710] [21180:000052e5] [ERROR][com.freerdp.utils.signal] - [winpr_log_backtrace_ex]: 9: dli_fname=/usr/lib/libfreerdp3.so.3 [0x7c6813c00000], dli_sname=(null) [(nil)]
[00:27:04:710] [21180:000052e5] [ERROR][com.freerdp.utils.signal] - [winpr_log_backtrace_ex]: 10: dli_fname=/usr/lib/libfreerdp-client3.so.3 [0x7c6813ecf000], dli_sname=(null) [(nil)]
[00:27:04:710] [21180:000052e5] [ERROR][com.freerdp.utils.signal] - [winpr_log_backtrace_ex]: 11: dli_fname=/usr/lib/libfreerdp-client3.so.3 [0x7c6813ecf000], dli_sname=(null) [(nil)]
[00:27:04:710] [21180:000052e5] [ERROR][com.freerdp.utils.signal] - [winpr_log_backtrace_ex]: 12: dli_fname=/usr/lib/libfreerdp-client3.so.3 [0x7c6813ecf000], dli_sname=(null) [(nil)]
[00:27:04:710] [21180:000052e5] [ERROR][com.freerdp.utils.signal] - [winpr_log_backtrace_ex]: 13: dli_fname=/usr/lib/libfreerdp-client3.so.3 [0x7c6813ecf000], dli_sname=(null) [(nil)]
[00:27:04:710] [21180:000052e5] [ERROR][com.freerdp.utils.signal] - [winpr_log_backtrace_ex]: 14: dli_fname=/usr/lib/libwinpr3.so.3 [0x7c6813ae9000], dli_sname=(null) [(nil)]
[00:27:04:710] [21180:000052e5] [ERROR][com.freerdp.utils.signal] - [winpr_log_backtrace_ex]: 15: dli_fname=/usr/lib/libc.so.6 [0x7c68136c0000], dli_sname=(null) [(nil)]
[00:27:04:710] [21180:000052e5] [ERROR][com.freerdp.utils.signal] - [winpr_log_backtrace_ex]: 16: dli_fname=/usr/lib/libc.so.6 [0x7c68136c0000], dli_sname=(null) [(nil)]
[00:27:04:710] [21180:000052e5] [ERROR][com.freerdp.utils.signal] - [winpr_log_backtrace_ex]: 17: unresolvable, address=(nil)
Aborted (core dumped)

I have tried taking the xfreerdp3 arguments to the bare bones (just ip and remote app). Tried various apps, all have the same issue. Sometimes they open, sometimes it crashes before opening with very similar logs as above. No issue with the previous version that was in the arch repos.

[akallabeth]

@fusion916 you´ve hit a bug.
we´ve added assertions (that should not be compiled in by release builds, check your package build!) that check some stuff that should not happen.

here the wrong copy function is called (the one that should not copy overlapped areas) with arguments that overlap.

[akallabeth]

@fusion916 can you run a debug build of this to get the location of where the wrong copy is called from?
tried this against my windows 10 test server, but don´t seem to hit it with that one.

[akallabeth]

@fusion916 also, to fix your issue in the release build, ensure -DWITH_VERBOSE_WINPR_ASSERT=OFF is set in your package build

[akallabeth]

@fusion916 ok, could reproduce the issue and already fixed it.
can you check it works for you?

[fusion916]

I rebuild from git and the issue appears to be fixed. Thanks.

[mrMoe]

@dvzrv Since you released the last version of this package to arch linux two days ago would you be able to look at this fix? Sadly I'm not able to contact you otherwise or create a bug report in the arch linux package repository so I hope this is ok if I bug you this way.

[dvzrv]

Since you released the last version of this package to arch linux two days ago would you be able to look at this fix?

Done.

Sadly I'm not able to contact you otherwise or create a bug report in the arch linux package repository so I hope this is ok if I bug you this way.

We do have our contact info available in the open (in the PKGBUILD, on the website) 😅
Generally, it is very much appreciated to open tickets with our gitlab instance instead of pinging over side-channels as there is 0% guarantee that they will work. With a ticket in our GitLab it has the highest likelihood in getting fixed.
(you literally only need to send a mail to the service desk - due to spam issues - to get signed up, which usually is a very fast process)

[akallabeth]

@dvzrv heads up:

• CMAKE_BUILD_TYPE=None will be explicitly checked and not work any more with next release (our build depends on using one of the basic CMake build types)
• you might want to set -DWITH_VERBOSE_WINPR_ASSERT=OFF to reduce code size and speed up the package

[dvzrv]

@dvzrv heads up:

* `CMAKE_BUILD_TYPE=None` will be explicitly checked and not work any more with next release (our build depends on using one of the basic `CMake` build types)

I see. That is unfortunately a bit problematic, as it overrides/ undoes our desired distribution wide compiler flags (for optimization, but also hardening), see https://wiki.archlinux.org/title/CMake_package_guidelines#CMake_can_automatically_override_the_default_compiler_optimization_flag

Is there a particular reason to not support the default None build type?

* you might want to set `-DWITH_VERBOSE_WINPR_ASSERT=OFF` to reduce code size and speed up the package

Thanks, I will check that out!

[akallabeth]

@dvzrv hmm, wouldn´t it be easy enough to patch your arch CMake to use desired optimizations or even just use a proper toolchain file with a preset you desire?

[edit]
a file toolchain.cmake with

set(CMAKE_C_FLAGS_RELEASE "-O1" CACHE STRING "bar")
set(CMAKE_C_FLAGS_DEBUG "-Og" CACHE STRING "bar")
set(CMAKE_C_FLAGS_RELWITHDEBINFO "-O1 -g" CACHE STRING "bar")
set(CMAKE_C_FLAGS_MINSIZEREL "-O3 -g" CACHE STRING "bar")

and CMake called with cmake -DCMAKE_TOOLCHAIN_FILE=toolchain.cmake ... just does that perfectly, so you don´t have to hack around buildtypes but just define your desired optimization level (and you can reuse that for any CMake project)

[dvzrv]

a file toolchain.cmake with

Interesting. I was not aware, that this was possible.
We'll have to evaluate if we can make use of it in the packaging context (as such an override of course should not apply to all invocations of cmake and needs to derive needed flags from our central location where flags are defined for packaging purposes).

Thanks for the input! 🙏