Note: This bug is displayed in read-only format because
the product is no longer active in Red Hat Bugzilla.
RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
Description of problem:
Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0x7fffecae9700 (LWP 28342)]
0x0000000000408552 in xf_gdi_memblt (context=0x6c5b60, memblt=0x6b2d38) at FreeRDP/client/X11/xf_gdi.c:602
602 XCopyArea(xfi->display, bitmap->pixmap, xfi->drawing, xfi->gc,
#0 0x0000000000408552 in xf_gdi_memblt (context=0x6c5b60, memblt=0x6b2d38) at FreeRDP/client/X11/xf_gdi.c:602
#1 0x00007ffff68369ad in update_gdi_memblt (context=0x6c5b60, memblt=0x6b2d38) at libfreerdp-cache/bitmap.c:37
#2 0x00007ffff65fb189 in update_recv_primary_order (update=0x6b06b0, s=0x7fffe802cd10, flags=65 'A') at FreeRDP/libfreerdp-core/orders.c:1781
#3 0x00007ffff65fbef3 in update_recv_order (update=0x6b06b0, s=0x7fffe802cd10) at FreeRDP/libfreerdp-core/orders.c:2018
#4 0x00007ffff660bc44 in fastpath_recv_orders (fastpath=0x6b48f0, s=0x7fffe802cd10) at FreeRDP/libfreerdp-core/fastpath.c:132
#5 0x00007ffff660be20 in fastpath_recv_update (fastpath=0x6b48f0, updateCode=0 '\000', size=614, s=0x7fffe802cd10)
at /home/oholy/Downloads/FreeRDP/libfreerdp-core/fastpath.c:173
#6 0x00007ffff660c34b in fastpath_recv_update_data (fastpath=0x6b48f0, s=0x7fffe802cd10) at FreeRDP/libfreerdp-core/fastpath.c:294
#7 0x00007ffff660c3d1 in fastpath_recv_updates (fastpath=0x6b48f0, s=0x7fffe802cd10) at FreeRDP/libfreerdp-core/fastpath.c:310
#8 0x00007ffff66094a6 in rdp_recv_fastpath_pdu (rdp=0x6a2200, s=0x7fffe802cd10) at FreeRDP/libfreerdp-core/rdp.c:763
#9 0x00007ffff66094f0 in rdp_recv_pdu (rdp=0x6a2200, s=0x7fffe802cd10) at FreeRDP/libfreerdp-core/rdp.c:771
#10 0x00007ffff66096a3 in rdp_recv_callback (transport=0x6a4080, s=0x7fffe802cd10, extra=0x6a2200) at FreeRDP/libfreerdp-core/rdp.c:831
#11 0x00007ffff660e6ab in transport_check_fds (ptransport=0x6a2250) at FreeRDP/libfreerdp-core/transport.c:359
#12 0x00007ffff660977f in rdp_check_fds (rdp=0x6a2200) at FreeRDP/libfreerdp-core/rdp.c:862
#13 0x00007ffff65fc263 in freerdp_check_fds (instance=0x6a2070) at FreeRDP/libfreerdp-core/freerdp.c:123
#14 0x0000000000414ac3 in xfreerdp_run (instance=0x6a2070) at FreeRDP/client/X11/xfreerdp.c:1054
#15 0x0000000000414c01 in thread_func (param=0x6c6830) at FreeRDP/client/X11/xfreerdp.c:1091
#16 0x00007ffff546860a in start_thread () from /lib64/libpthread.so.0
#17 0x00007ffff51a2a4d in clone () from /lib64/libc.so.6
How reproducible:
It happens randomly, usually immediately after xfreerdp window is shown. I saw this crashes only when connecting to Windows 2012, however according the upstream patch it is happening also for Windows XP at least. Any special cmd options aren't needed, however I see this more often (with less then 5 attempts) when connecting using rdp security without additional credentials...
Steps to Reproduce:
1. xfreerdp --sec rdp win2012server
Additional info:
It has been fixed upstream by the following commit:
https://github.com/FreeRDP/FreeRDP/commit/46a691db029912e5814b0c6fb36002a41e597825
The commit is easy backportable.
It seems that servers can ask for cached bitmaps that they haven't been defined. We can simply ignore such requests in order to fix this crashes.
During executing command "xfreerdp --sec rdp <win2012serverIP>" 12 times the crash did not happen. Suppose it is fixed. Tested on RHEL 7.3 with kernel-3.10.0-493.el7.x86_64 and freerdp-1.0.2-10.el7.x86_64.
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.
For information on the advisory, and where to find the updated
files, follow the link below.
If the solution does not work for you, open a new bug report.
https://rhn.redhat.com/errata/RHBA-2016-2261.html
Description of problem: Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 0x7fffecae9700 (LWP 28342)] 0x0000000000408552 in xf_gdi_memblt (context=0x6c5b60, memblt=0x6b2d38) at FreeRDP/client/X11/xf_gdi.c:602 602 XCopyArea(xfi->display, bitmap->pixmap, xfi->drawing, xfi->gc, #0 0x0000000000408552 in xf_gdi_memblt (context=0x6c5b60, memblt=0x6b2d38) at FreeRDP/client/X11/xf_gdi.c:602 #1 0x00007ffff68369ad in update_gdi_memblt (context=0x6c5b60, memblt=0x6b2d38) at libfreerdp-cache/bitmap.c:37 #2 0x00007ffff65fb189 in update_recv_primary_order (update=0x6b06b0, s=0x7fffe802cd10, flags=65 'A') at FreeRDP/libfreerdp-core/orders.c:1781 #3 0x00007ffff65fbef3 in update_recv_order (update=0x6b06b0, s=0x7fffe802cd10) at FreeRDP/libfreerdp-core/orders.c:2018 #4 0x00007ffff660bc44 in fastpath_recv_orders (fastpath=0x6b48f0, s=0x7fffe802cd10) at FreeRDP/libfreerdp-core/fastpath.c:132 #5 0x00007ffff660be20 in fastpath_recv_update (fastpath=0x6b48f0, updateCode=0 '\000', size=614, s=0x7fffe802cd10) at /home/oholy/Downloads/FreeRDP/libfreerdp-core/fastpath.c:173 #6 0x00007ffff660c34b in fastpath_recv_update_data (fastpath=0x6b48f0, s=0x7fffe802cd10) at FreeRDP/libfreerdp-core/fastpath.c:294 #7 0x00007ffff660c3d1 in fastpath_recv_updates (fastpath=0x6b48f0, s=0x7fffe802cd10) at FreeRDP/libfreerdp-core/fastpath.c:310 #8 0x00007ffff66094a6 in rdp_recv_fastpath_pdu (rdp=0x6a2200, s=0x7fffe802cd10) at FreeRDP/libfreerdp-core/rdp.c:763 #9 0x00007ffff66094f0 in rdp_recv_pdu (rdp=0x6a2200, s=0x7fffe802cd10) at FreeRDP/libfreerdp-core/rdp.c:771 #10 0x00007ffff66096a3 in rdp_recv_callback (transport=0x6a4080, s=0x7fffe802cd10, extra=0x6a2200) at FreeRDP/libfreerdp-core/rdp.c:831 #11 0x00007ffff660e6ab in transport_check_fds (ptransport=0x6a2250) at FreeRDP/libfreerdp-core/transport.c:359 #12 0x00007ffff660977f in rdp_check_fds (rdp=0x6a2200) at FreeRDP/libfreerdp-core/rdp.c:862 #13 0x00007ffff65fc263 in freerdp_check_fds (instance=0x6a2070) at FreeRDP/libfreerdp-core/freerdp.c:123 #14 0x0000000000414ac3 in xfreerdp_run (instance=0x6a2070) at FreeRDP/client/X11/xfreerdp.c:1054 #15 0x0000000000414c01 in thread_func (param=0x6c6830) at FreeRDP/client/X11/xfreerdp.c:1091 #16 0x00007ffff546860a in start_thread () from /lib64/libpthread.so.0 #17 0x00007ffff51a2a4d in clone () from /lib64/libc.so.6 How reproducible: It happens randomly, usually immediately after xfreerdp window is shown. I saw this crashes only when connecting to Windows 2012, however according the upstream patch it is happening also for Windows XP at least. Any special cmd options aren't needed, however I see this more often (with less then 5 attempts) when connecting using rdp security without additional credentials... Steps to Reproduce: 1. xfreerdp --sec rdp win2012server Additional info: It has been fixed upstream by the following commit: https://github.com/FreeRDP/FreeRDP/commit/46a691db029912e5814b0c6fb36002a41e597825 The commit is easy backportable. It seems that servers can ask for cached bitmaps that they haven't been defined. We can simply ignore such requests in order to fix this crashes.