Xorg crashes when closing xfreerdp session in xrdp

[pieska]

I encountered a strange issue with xrdp.

Setup is as follows:

opening a session a with mstc (win7) to xrdp (xorgrdp) on rhel7.
opening a session b with xfreerdp 1.0 or 2.0 in session a to a windows host.
closing session b closes session b AND session A will be killed by segfault in Xorg.

xorgxrdp.log

[jsorg71]

I looks like a crash in damage X11 extension. Good find.
Can you turn off damage extension in /etc/X11/xrdp/xorg.conf ?
I have to look up how to do that.

[jsorg71]

I tried myself, to turn off damage, you have to do it with -extension DAMAGE in sesman.ini.
It looks like xorgxrdp does not work without damage.

[jsorg71]

I just tried with Debian 9, seems to work.
I noticed your is Xorg server version 1.20, Debian 9 has 1.19.
I used FreeRDP version 2.0.0-rc4 inside the xrdp session.

[pieska]

I tried it without DAMAGE:

xorgxrdp_wo_DAMAGE.log

xorg starts but not the window manager (gnome). xterm as wm works but as soon as i start an xfreerdp session in xterm xorg crashes

xorgxrdp_wo_DAMAGE_w_XTERM.log

XOrg 1.20.1, free 1.0.2 but i tried freerdp 2.0 too.

[shollander]

I am having the exact same issue. Please fix.

[didierjrichard]

Same here (mstsc -> xrdp on a RHEL7 VM), disconnecting a xfreerdp connection breaks XRDP and logs out.
I noticed that this does not happen when the xfreerdp client is started full-screen (-f)
Also noticed that the DISPLAY increases for XRDP at every crash (eg :10 then :11 then :12 .... )
Does this corrupt the XOrg server to the point the it drops the active DISPLAY ?

[Mikky83]

Dear All,
We are getting the same issue. Xorg under xrdp crashes every time when xfreerdp session is closed/disconnected. OS: CentOS 7.7
DISPLAY increases at every crash and causes issues with reaching the max connections. In order to fix it, files under /tmp/.xrdp/ should be deleted.
Does anyone have any update on this? I'm wondering whether update to CentOS7.8 will solve the issue.

[Mikky83]

Just an update, the same behaviour is there with:
CentOS/RHEL 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
xrdp-0.9.13-2.el7.x86_64

It seems that the latest stable environment was using CentOS/RHEL 7.5. After update to 7.6, problems started and it is not fixed yet. It's already reported to redhat bugzilla and freerdp teams.

[matt335672]

I can't reproduce this.

I've got a Win 10 client connecting to a CentOS 7.8 machine with two users.

Connection a: Win 10 -> CentOS logging in with Xorg backend on first user
Connection b: "xfreerdp /v:localhost /relax-order-checks +glyph-cache" , using 2nd user.

Can anyone who is experiencing this give me any clues as to differences?

My versions are identical to @Mikky83 with the addition of:-

xorgxrdp-0.2.13-1.el7.x86_64

Thanks,

[Mikky83]

Dear @matt335672, many thanks for following up this. In order to reproduce it, please create one more win10 VM and configure it for remote access. It's happening only with Windows machines. And each Windows distribution has specific behaviour. The common for all of them is xfreerdp crash the X server on disconnection.
Then from xrdp session to CentOS, try "xfreerdp -u username $newwin10_IP".
If you disable the channels and multi monitor options into xrdp/sessman conf, xfreerdp will open the connection. But when you log off from the windows session, it will crash with segmentation fault.
Everything works fine with Xvnc as a backend.

freerdp team is blaming redhat for the problem and they said that don't plan to change anything related with X11 part in xfreerdp.

[matt335672]

Thanks for that.

I've just started a download of the latest Windows 10 ISO so I can set up a VM as a target. It may take me a while to get it all configured.

In the meantime, have you got a reference to the conversation between freerdp and redhat about this? It may be quite informative. Also we may also have some input into it too (depending on what we find out).

Thanks.

[matt335672]

Hi @Mikky83

I still can't reproduce this.

I'm going Win 10 (physical) -> CentOS7 -> Win 10 (VM) and all is well.

• Windows 10 version is 2004 on both machines.
• Physical machine has one monitor (800x600 - it's an old netbook)
• Physical machine has no video acceleration
• I'm starting a 1280x1024 session on the CentOS machine (i.e. larger than the physical screen)
• From the CentOS machine, I've tried xfreerdp -u username $newwin10_IP and xfreerdp -u username $hostname

I'm running the Xorg server on the CentOS machine under valgrind, and it's not showing anything unusual.

A couple of questions for you:-

• Is the above scenario representative of something you have which shows the issue? If not, what is your setup?
• Can you please post xrdp.ini and sesman.ini from the CentOS machine?
• Can you also post the RDP connection file you're making your initial connection with?
• Are you doing anything on the win 10 target when you log in? I've set up a bare VM, so it won't be running anything unusual or unexpected on login. Are you starting a browser for example?

Thanks

[Mikky83]

Hi @matt335672 ,
Thanks for the inputs. What I didn't try to change during my troubleshooting was the desktop environment. I'm stick with xfce because it showed the best performance in our case. Also I connect to xrdp from a VM (horizon VDI), but I've tested with direct connection from a notebook, it was the same.
Could you try to install xfce and use it as a desktop environment?

Regarding the references:
https://bugzilla.redhat.com/show_bug.cgi?id=1659113
FreeRDP/FreeRDP#6290

[matt335672]

Great - thanks.

Leave it with me.

[matt335672]

Well I'm getting plenty of crashes with XFCE4, although all I have to do is run xfreerdp - I don't need to even exit the session.

I can't be sure yet whether this is xorgxrdp or X server related (or both) so I'll continue digging.

For reference, I've attached a trace I'm getting from valgrind when the X server goes down.
valgrind.log

I'll carry on looking at this next week. If I do decide it's an X server issue I'll add more info to the bugzilla.

[Mikky83]

Hi @matt335672, great to hear that you were able to reproduce the problem. So, now we know that it happens only when you use xfce4 as desktop environment.

I can provide some additional details about xorg server crashes.
If you change the xrdp configuration to use only one monitor and disable the channels, you will be able to open xfreerdp session. But, the crash will occur when you disconnect the windows RDP session.
And if you try to connect to older version of windows (e.g. 2008) it will work, but it will crash on session disconnect.

So, as you said, I'm leaving to you. In case if you need some additional details please let me know.
Many thanks for your support!
Cheers!

[matt335672]

Having spent quite a bit of time on this, I've managed to confirm it's nothing to do with xorgxrdp - I've managed to reproduce it on a CentOS 7.8 VM without using xorgxrdp.

I've added a bit more technical info to https://bugzilla.redhat.com/show_bug.cgi?id=1659113 on what's happening inside the X server when this happens. I'm in a position to add to this information if Red Hat ask me to do so.

@Mikky83 - thanks for your help in getting this reproduced. I'm just sorry I can't give you a more positive response right now.

[danielperna84]

Even though it might not be relevant for the problem, a workaround that works for me is using Remmina (version 1.4.1-1, haven't updated yet) as the RDP client. Oddly enough, Remmina is using the same library as xfreerdp, yet it doesn't crash.

ldd /usr/lib64/remmina/plugins/remmina-plugin-rdp.so | grep rdp
	libfreerdp2.so.2 => /lib64/libfreerdp2.so.2 (0x00007fd642bcb000)
	libfreerdp-client2.so.2 => /lib64/libfreerdp-client2.so.2 (0x00007fd64296d000)

ldd /bin/xfreerdp | grep rdp
	libfreerdp-client2.so.2 => /lib64/libfreerdp-client2.so.2 (0x00007f0dadbc4000)
	libfreerdp2.so.2 => /lib64/libfreerdp2.so.2 (0x00007f0dad87f000)

[matt335672]

The Red Hat bugzilla entry above has been updated as "CLOSED WONTFIX".

I'm closing this issue here too, as there's nothing we can do about it. If anyone on this thread has any leverage with Red Hat and can get the bugzilla re-opened, I'll re-open this issue too.