Bug 1659113 - After upgrade to EL7.6, xfreerdp crashes the X server.
Summary: After upgrade to EL7.6, xfreerdp crashes the X server.
Keywords:
Status: CLOSED WONTFIX
Alias: None
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: xorg-x11-server
Version: 7.7
Hardware: x86_64
OS: Linux
unspecified
unspecified
Target Milestone: rc
: ---
Assignee: Adam Jackson
QA Contact: Desktop QE
URL:
Whiteboard:
: 1789935 (view as bug list)
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2018-12-13 15:37 UTC by gyuyjxz5kv
Modified: 2020-11-11 21:39 UTC (History)
15 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2020-11-11 21:39:35 UTC
Target Upstream Version:
gyuyjxz5kv: needinfo-


Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Red Hat Knowledge Base (Solution) 4728461 0 None None None 2020-02-05 10:00:50 UTC

Description gyuyjxz5kv 2018-12-13 15:37:07 UTC
Description of problem:  Attempting to start xfreerdp crashes X server


Version-Release number of selected component (if applicable): freerdp-1.0.2-15.el7.x86_64


How reproducible: Every time


Steps to Reproduce:
1. Log in to X session
2. Run xfreerdp <servername>
3.

Actual results: X crashes


Expected results: xrdp should connect to server

Additional info:
Affected machine is Lenovo Thinkpad X1, 3rd generation (2015).    Lspci
says
VGA compatible controller: Intel Corporation HD Graphics 5500 (rev 09)

xfreerdp worked as advertised under EL7.5

Last lines in /var/log/Xorg.0.log are
[  1037.968] (EE) 
[  1037.968] (EE) Backtrace:
[  1037.968] (EE) 0: /usr/bin/X (xorg_backtrace+0x55) [0x562ee2b870f5]
[  1037.968] (EE) 1: /usr/bin/X (0x562ee29d6000+0x1b4d79) [0x562ee2b8ad79]
[  1037.968] (EE) 2: /lib64/libpthread.so.0 (0x7ffaa6b1f000+0xf5d0) [0x7ffaa6b2e
5d0]
[  1037.968] (EE) 3: /usr/bin/X (miHandleValidateExposures+0x29) [0x562ee2b7f919
]
[  1037.968] (EE) 4: /usr/bin/X (0x562ee29d6000+0x8652f) [0x562ee2a5c52f]
[  1037.968] (EE) 5: /usr/bin/X (ConfigureWindow+0xa94) [0x562ee2a5d684]
[  1037.968] (EE) 6: /usr/bin/X (0x562ee29d6000+0x569b8) [0x562ee2a2c9b8]
[  1037.968] (EE) 7: /usr/bin/X (0x562ee29d6000+0x5c35b) [0x562ee2a3235b]
[  1037.968] (EE) 8: /usr/bin/X (0x562ee29d6000+0x603aa) [0x562ee2a363aa]
[  1037.969] (EE) 9: /lib64/libc.so.6 (__libc_start_main+0xf5) [0x7ffaa67743d5]
[  1037.969] (EE) 10: /usr/bin/X (0x562ee29d6000+0x4a4ce) [0x562ee2a204ce]
[  1037.969] (EE) 
[  1037.969] (EE) Segmentation fault at address 0x0
[  1037.969] (EE) 
Fatal server error:
[  1037.969] (EE) Caught signal 11 (Segmentation fault). Server aborting
[  1037.969] (EE) 
[  1037.969] (EE) 
Please consult the The X.Org Foundation support 
	 at http://wiki.x.org
 for help. 
[  1037.969] (EE) Please also check the log file at "/var/log/Xorg.0.log" for ad
ditional information.
[  1037.969] (EE) 
[  1037.969] (II) AIGLX: Suspending AIGLX clients for VT switch
[  1038.060] (EE) Server terminated with error (1). Closing log file.

Comment 1 Simone Caronni 2019-02-28 18:24:59 UTC
Reassigning to the correct product.

Comment 3 Ondrej Holy 2019-03-01 10:02:14 UTC
Thanks for your bug report. I need more info to proceed. Is this always reproducible? Does xfreerdp return some error? Which xfreerdp options have you used? Are you trying to connect to xrdp server? Does the X server crashes on a client, or on a server?

Comment 4 Ondrej Holy 2019-03-01 10:11:43 UTC
Just a note that there were no functional changes in freerdp codes between RHEL 7.6 and RHEL 7.5, so I suppose that this is a bug in another component.

Comment 5 gyuyjxz5kv 2019-03-01 17:59:44 UTC
(In reply to Ondrej Holy from comment #3)
> Thanks for your bug report. I need more info to proceed. Is this always
> reproducible? Does xfreerdp return some error? Which xfreerdp options have
> you used? Are you trying to connect to xrdp server? Does the X server
> crashes on a client, or on a server?

Yes, reproducible every time.
No, xfreerdp doesn't get a chance to return an error, or at least I don't get to see
it, because the X session abruptly ends as the server crashes.
Yes, I am trying to connect to an xrdp server, which is running on an el7
machine.
The X server on the client crashes.  I don't think that there is any consequence
on the server machine.

Comment 6 gyuyjxz5kv 2019-03-01 18:04:21 UTC
(In reply to Ondrej Holy from comment #4)
> Just a note that there were no functional changes in freerdp codes between
> RHEL 7.6 and RHEL 7.5, so I suppose that this is a bug in another component.

It certainly seems like a weakness in the X server that a client is
able to crash it.

Comment 7 Ondrej Holy 2019-03-06 09:30:43 UTC
Given the fact, that I don't have any idea how to debug this and that there were no functional changes in freerdp codes, I am changing the component to xorg-x11-server.

Comment 8 A. Fernando 2019-06-13 16:19:55 UTC
It appears I seem to have the same issue with xfreerdp / Gnome3 & KDEP desktops

I am using RHEL 7.6 / freerdp-1.0.2-15.el7 in multi display environment.
I use Nvidia 430.14 driver.

I used dual displays, rotated, i.e. vertical with KDE. When I launch xfreerdp command x server crashes and produces a bactrace.
Situation is similar in Gnome3 Plasma desktop resulting x-server crash and backtrace.

Backtrace e.g.:

<snip>
0: /usr/bin/X (xorg_backtrace+0x55) [0x562091e8c0f5]
1: /usr/bin/X (0x562091cdb000+0x1b4d79) [0x562091e8fd79]
2: /lib64/libpthread.so.0 (0x7f2bdd011000+0xf5d0) [0x7f2bdd0205d0]
3: /usr/lib64/xorg/modules/drivers/nvidia_drv.so (0x7f2bd8b17000+0xad040) [0x7f2bd8bc4040]
4: /usr/lib64/xorg/modules/libwfb.so (wfbSolid+0x331) [0x7f2bd86f6a51]
5: /usr/lib64/xorg/modules/libwfb.so (wfbFill+0x50f) [0x7f2bd86edfcf]
6: /usr/lib64/xorg/modules/libwfb.so (wfbPolyFillRect+0x1a0) [0x7f2bd86eeb20]
7: /usr/lib64/xorg/modules/drivers/nvidia_drv.so (0x7f2bd8b17000+0x4f62a2) [0x7f2bd900d2a2]
<snip>

Above backtraces complains about the x-server, xorg-x11-server-Xorg-1.20.1-5.3.el7_6.x86_64, which comes with RH 7.6

I kind of narrowed down my issue to the vertically rotated displays.

When I leave the displays default without any rotation xfreerdp doesn't cause x-server to crash in either Gnome3 or KDE desktops.
Then I kept one display horizontal/default (no rotation) then the other rotated vertically.
In the non-rotated display xfreerdp cause no x-server crash and the vertical display causes xfreerdp to crash.

With the previous ver of xfreerdp freerdp-1.0.2-10 / RH 7.4 & exorg-x11-server-Xorg-1.19.3-11.el7_4.2.x86_64 environment I didn't experience any problems, i.e. x-server crashes with any display mode.

Comment 11 Ondrej Holy 2019-09-10 08:16:48 UTC
(In reply to A. Fernando from comment #8)
> It appears I seem to have the same issue with xfreerdp / Gnome3 & KDEP
> desktops
> 
> I am using RHEL 7.6 / freerdp-1.0.2-15.el7 in multi display environment.
> I use Nvidia 430.14 driver.
> 
> I used dual displays, rotated, i.e. vertical with KDE. When I launch
> xfreerdp command x server crashes and produces a bactrace.
> Situation is similar in Gnome3 Plasma desktop resulting x-server crash and
> backtrace.
> 
> Backtrace e.g.:
> 
> <snip>
> 0: /usr/bin/X (xorg_backtrace+0x55) [0x562091e8c0f5]
> 1: /usr/bin/X (0x562091cdb000+0x1b4d79) [0x562091e8fd79]
> 2: /lib64/libpthread.so.0 (0x7f2bdd011000+0xf5d0) [0x7f2bdd0205d0]
> 3: /usr/lib64/xorg/modules/drivers/nvidia_drv.so (0x7f2bd8b17000+0xad040)
> [0x7f2bd8bc4040]
> 4: /usr/lib64/xorg/modules/libwfb.so (wfbSolid+0x331) [0x7f2bd86f6a51]
> 5: /usr/lib64/xorg/modules/libwfb.so (wfbFill+0x50f) [0x7f2bd86edfcf]
> 6: /usr/lib64/xorg/modules/libwfb.so (wfbPolyFillRect+0x1a0) [0x7f2bd86eeb20]
> 7: /usr/lib64/xorg/modules/drivers/nvidia_drv.so (0x7f2bd8b17000+0x4f62a2)
> [0x7f2bd900d2a2]
> <snip>
> 
> Above backtraces complains about the x-server,
> xorg-x11-server-Xorg-1.20.1-5.3.el7_6.x86_64, which comes with RH 7.6
> 
> I kind of narrowed down my issue to the vertically rotated displays.
> 
> When I leave the displays default without any rotation xfreerdp doesn't
> cause x-server to crash in either Gnome3 or KDE desktops.
> Then I kept one display horizontal/default (no rotation) then the other
> rotated vertically.
> In the non-rotated display xfreerdp cause no x-server crash and the vertical
> display causes xfreerdp to crash.
> 
> With the previous ver of xfreerdp freerdp-1.0.2-10 / RH 7.4 &
> exorg-x11-server-Xorg-1.19.3-11.el7_4.2.x86_64 environment I didn't
> experience any problems, i.e. x-server crashes with any display mode.

This is likely another issue as the backtrace is totally different.

Comment 13 A. Fernando 2019-09-16 07:26:29 UTC
I noticed the release of freerdp-2.0.0-1.rc4.el7.x86_64.
As of now, it is only available in 64 bit format.
I tried but causing pkg conflicts upgrading from freerdp-1.0.2-15.el7.x86_64 on RHEL 7.6

e.g. Error: Package: freerdp-2.0.0-1.rc4.el7.x86_64 (/freerdp-2.0.0-1.rc4.el7.x86_64)
           Requires: libfreerdp2.so.2()(64bit)

Comment 14 Ondrej Holy 2019-10-01 11:42:04 UTC
(In reply to A. Fernando from comment #13)
> I noticed the release of freerdp-2.0.0-1.rc4.el7.x86_64.
> As of now, it is only available in 64 bit format.
> I tried but causing pkg conflicts upgrading from freerdp-1.0.2-15.el7.x86_64
> on RHEL 7.6
> 
> e.g. Error: Package: freerdp-2.0.0-1.rc4.el7.x86_64
> (/freerdp-2.0.0-1.rc4.el7.x86_64)
>            Requires: libfreerdp2.so.2()(64bit)

This isn't related to this bug. If you see some issues with the freerdp package, please report that as a separate bug report. Thanks!

Comment 15 Ondrej Holy 2019-10-01 11:44:59 UTC
It seems that I am not able to reproduce it, however, in theory, "xfreerdp --gdi sw" might help as it uses different x11 methods.

Comment 16 gyuyjxz5kv 2019-10-01 13:08:27 UTC
(In reply to Ondrej Holy from comment #15)
> It seems that I am not able to reproduce it, however, in theory, "xfreerdp
> --gdi sw" might help as it uses different x11 methods.

Thanks for the suggestion, but including that option doesn't appear to make any difference.
The server still crashes.

Comment 17 Ondrej Holy 2019-10-02 09:07:05 UTC
Hmm, I am still trying to reproduce it, but without success. When does it crash, immediately after connect? Does it happen just with just "xfreerdp -u user -p password server", or do you use some options? What is your xrdp version?

Comment 18 gyuyjxz5kv 2019-10-02 11:51:03 UTC
(In reply to Ondrej Holy from comment #17)
> Hmm, I am still trying to reproduce it, but without success. When does it
> crash, immediately after connect? Does it happen just with just "xfreerdp -u
> user -p password server", or do you use some options? What is your xrdp
> version?

I can't actually tell whether it connects or not.  The local X server goes down immediately after I
hit return on the command line.
Just username and server, no other options (except the time when I tried --gdi sw at your
suggestion).
xrdp-0.9.11-1.el7.x86_64 from epel.
Since you say that there has been no functional change in xrdp, the place to look may be in some
change to the X server that came in between EL7.5 and EL7.6.
By the way, I am able to connect to the same remote xrdp server with remmina.

Comment 20 gyuyjxz5kv 2020-01-28 19:34:45 UTC
Could https://bugzilla.redhat.com/show_bug.cgi?id=1671183 be related?

Comment 21 Ondrej Holy 2020-02-05 10:00:50 UTC
*** Bug 1789935 has been marked as a duplicate of this bug. ***

Comment 25 Mikky83 2020-06-17 10:19:02 UTC
Dear all,
Does anybody have a solution for this?
It's happening with latest packages of freerdp and xorg on RHEL/CentOS 7.8

freerdp-libs-2.0.0-4.rc4.el7_8.x86_64
freerdp-2.0.0-4.rc4.el7_8.x86_64
xorg-x11-server-Xorg-1.20.4-10.el7.x86_64

Comment 26 gyuyjxz5kv 2020-06-22 13:16:07 UTC
I can confirm that it is still happening.  I don't have relevant expertise to propose a solution.  (Sorry for the noise, I'm being pestered for a response by the bugzilla.)

Comment 27 matt335672 2020-07-03 13:44:39 UTC
I've been looking into this as the same fault has been registered against xorgxrdp (see https://github.com/neutrinolabs/xorgxrdp/issues/137)

Having reproduced in using xrdp, I've now managed to reproduce it using just the console X server on a CentOS 7.8 VM (i.e. without xorgxrdp or xrdp). This is done as follows. I have not looked into exactly whether all of these steps are required:-

- Install XFCE. The same fault does (oddly) not manifest with GNOME.
- On the console, log in an XFCE session of size 1280x1024
- Use the command "xfreerdp -u <user> win10target" to connect to a Win10 machine.
- Enter null domain and a password and the X server goes down.

Virtual display hardware is the QXL framebuffer.

During my debugging sessions on xorgxrdp, I've also managed to determine that when this happens, the pixman_fill() routine is being called with a y value of -2. I'm by no means an X server internals expert but this doesn't look right to me. Furthermore, this doesn't always result in an immediate crash, but occasionally just scribbles over other data structures.

I've rebuilt the pixman RPM with the following patch:-

--------------------------------------------------------------------------------

--- pixman/pixman.c.orig	2015-12-27 20:37:37.000000000 +0000
+++ pixman/pixman.c	2020-07-03 13:12:01.848907314 +0100
@@ -756,6 +756,7 @@
              int       height,
              uint32_t  filler)
 {
+    if (x < 0 || y < 0) abort();
     return _pixman_implementation_fill (
 	get_implementation(), bits, stride, bpp, x, y, width, height, filler);
 }

--------------------------------------------------------------------------------

This leads to a stack dump which looks like this:-


(gdb) where
#0  0x00007efda2b25387 in raise () from /lib64/libc.so.6
#1  0x00007efda2b26a78 in abort () from /lib64/libc.so.6
#2  0x00007efda4490b9e in pixman_fill (bits=bits@entry=0x55828af5a658, stride=stride@entry=1024, bpp=bpp@entry=32, x=x@entry=3, y=y@entry=-2, 
    width=width@entry=1024, height=height@entry=768, filler=0) at pixman.c:759
#3  0x00007efd9dec840d in fbFill (pDrawable=pDrawable@entry=0x55828a710f20, pGC=pGC@entry=0x55828a166530, x=x@entry=3, y=y@entry=29, 
    width=width@entry=1024, height=height@entry=768) at fbfill.c:125
#4  0x00007efd9dec8c60 in fbPolyFillRect (pDrawable=0x55828a710f20, pGC=0x55828a166530, nrect=<optimized out>, prect=0x55828a70f728) at fbfillrect.c:72
#5  0x0000558288590c86 in damagePolyFillRect (pDrawable=0x55828a710f20, pGC=0x55828a166530, nRects=1, pRects=<optimized out>) at damage.c:1224
#6  0x00005582885eaa47 in miPaintWindow (pWin=<optimized out>, prgn=<optimized out>, what=<optimized out>) at miexpose.c:540
#7  0x00005582885ea74d in miWindowExposures (pWin=0x55828a710f20, prgn=0x55828a7120a0) at miexpose.c:394
#8  0x00005582885395b9 in compWindowExposures (pWin=0x55828a710f20, reg=0x55828a7120a0) at compwindow.c:315
#9  0x00005582885febdc in miHandleValidateExposures (pWin=0x55828a711eb0) at miwindow.c:226
#10 0x000055828853b212 in compHandleMarkedWindows (pLayerWin=0x55828a710f20, pWin=<optimized out>) at compalloc.c:127
#11 0x000055828853c468 in compFreeClientWindow (pWin=0x55828a710f20, id=<optimized out>) at compalloc.c:309
#12 0x0000558288536fc9 in FreeCompositeClientWindow (value=<optimized out>, ccwid=<optimized out>) at compext.c:74
#13 0x00005582884d5b22 in doFreeResource (res=0x55828a6af400, skip=0) at resource.c:880
#14 0x00005582884d66fe in FreeResource (id=1084228491, skipDeleteFuncType=skipDeleteFuncType@entry=0) at resource.c:910
#15 0x000055828853b971 in compUnredirectWindow (pClient=0x55828a4160a0, pWin=pWin@entry=0x55828a710f20, update=update@entry=1) at compalloc.c:332
#16 0x000055828853c0fb in compUnredirectOneSubwindow (pParent=pParent@entry=0x55828a1f62f0, pWin=pWin@entry=0x55828a710f20) at compalloc.c:521
#17 0x000055828853a6cb in compReparentWindow (pWin=0x55828a710f20, pPriorParent=0x55828a1f62f0) at compwindow.c:504
#18 0x00005582884e01c7 in ReparentWindow (pWin=0x55828a710f20, pParent=0x55828a711eb0, x=<optimized out>, y=<optimized out>, 
    client=client@entry=0x55828a4160a0) at window.c:2601
#19 0x00005582884ab81c in ProcReparentWindow (client=0x55828a4160a0) at dispatch.c:829
#20 0x00005582884b143b in Dispatch () at dispatch.c:478
#21 0x00005582884b548a in dix_main (argc=15, argv=0x7ffdf41b4e68, envp=<optimized out>) at main.c:276
#22 0x00007efda2b11555 in __libc_start_main () from /lib64/libc.so.6
#23 0x000055828849f57e in _start ()

Bear in mind I'm on a CentOS 7.8 VM rather than a RHEL one.

I'm happy to park this VM and provide more information as requested.

Comment 28 kevin martin 2020-09-25 03:11:57 UTC
FWIW, downloading the FreeRDP source code from github and compiling on Oracle Linux 7 with cmake gives me a functioning xfreerdp with xfce again.

Comment 30 Chris Williams 2020-11-11 21:39:35 UTC
Red Hat Enterprise Linux 7 shipped it's final minor release on September 29th, 2020. 7.9 was the last minor releases scheduled for RHEL 7.
From intial triage it does not appear the remaining Bugzillas meet the inclusion criteria for Maintenance Phase 2 and will now be closed. 

From the RHEL life cycle page:
https://access.redhat.com/support/policy/updates/errata#Maintenance_Support_2_Phase
"During Maintenance Support 2 Phase for Red Hat Enterprise Linux version 7,Red Hat defined Critical and Important impact Security Advisories (RHSAs) and selected (at Red Hat discretion) Urgent Priority Bug Fix Advisories (RHBAs) may be released as they become available."

If this BZ was closed in error and meets the above criteria please re-open it flag for 7.9.z, provide suitable business and technical justifications, and follow the process for Accelerated Fixes:
https://source.redhat.com/groups/public/pnt-cxno/pnt_customer_experience_and_operations_wiki/support_delivery_accelerated_fix_release_handbook  

Feature Requests can re-opened and moved to RHEL 8 if the desired functionality is not already present in the product. 

Please reach out to the applicable Product Experience Engineer[0] if you have any questions or concerns.  

[0] https://bugzilla.redhat.com/page.cgi?id=agile_component_mapping.html&product=Red+Hat+Enterprise+Linux+7


Note You need to log in before you can comment on or make changes to this bug.