Bug 1659113

Reassigning to the correct product.

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?

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.

(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.

(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.

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.

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.

(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.

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)

(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!

It seems that I am not able to reproduce it, however, in theory, "xfreerdp --gdi sw" might help as it uses different x11 methods.

(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.

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?

(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.

Could https://bugzilla.redhat.com/show_bug.cgi?id=1671183 be related?

*** Bug 1789935 has been marked as a duplicate of this bug. ***

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

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.)

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.

FWIW, downloading the FreeRDP source code from github and compiling on Oracle Linux 7 with cmake gives me a functioning xfreerdp with xfce again.

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