xrdp-chansrv become defunct in docker while file copy

[endofreal]

Hi!

I work on some variant of VDI based on xrdp server in docker image and faced a problem what xrdp-chansrv become defunct while I click on copy file in my Windows 10 machine.

I tried to use strace to know cause it happens. Output:

strace -fp `pgrep xrdp-chansrv`
strace: Process 1373 attached with 2 threads
[pid  1379] select(16, [4 10 11 12 13 14 15], [], NULL, NULL <unfinished ...>
[pid  1373] select(9, [4 8], [], NULL, NULL <unfinished ...>
[pid  1379] <... select resumed>)       = 1 (in [12])
[pid  1379] select(5, [4], NULL, NULL, {tv_sec=0, tv_usec=0}) = 0 (Timeout)
[pid  1379] select(13, [12], NULL, NULL, {tv_sec=0, tv_usec=0}) = 1 (in [12], left {tv_sec=0, tv_usec=0})
[pid  1379] recvfrom(12, "\0\0\0\0\234\0\0\0", 8, 0, NULL, NULL) = 8
[pid  1379] stat("/etc/localtime", {st_mode=S_IFREG|0644, st_size=1535, ...}) = 0
[pid  1379] recvfrom(12, "\5\0\0\0\224\0\0\0\2\0\23\0\202\0\202\0\0\0\2\0\0\0z\0\0\0\6\301\0\0F\0"..., 148, 0, NULL, NULL) = 148
[pid  1379] stat("/etc/localtime", {st_mode=S_IFREG|0644, st_size=1535, ...}) = 0
[pid  1379] select(13, NULL, [12], NULL, {tv_sec=0, tv_usec=0}) = 1 (out [12], left {tv_sec=0, tv_usec=0})
[pid  1379] sendto(12, "\0\0\0\0&\0\0\0\10\0\0\0\36\0\0\0\2\0\3\0\f\0\f\0\0\0\3\0\1\0\0\0"..., 38, 0, NULL, 0) = 38
[pid  1379] poll([{fd=11, events=POLLIN|POLLOUT}], 1, -1) = 1 ([{fd=11, revents=POLLOUT}])
[pid  1379] writev(11, [{iov_base="\22\2\6\0\1\0`\0\370\0\0\0\37\0\0\0\10\0\2\0\0\0\0\0", iov_len=24}, {iov_base=NULL, iov_len=0}, {iov_base="", iov_len=0}], 3) = 24
[pid  1379] poll([{fd=11, events=POLLIN}], 1, -1) = 1 ([{fd=11, revents=POLLIN}])
[pid  1379] recvmsg(11, {msg_name=NULL, msg_namelen=0, msg_iov=[{iov_base="\34\0E\0\1\0`\0\370\0\0\0\305\250\334H\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0", iov_len=4096}], msg_iovlen=1, msg_controllen=0, msg_flags=0}, 0) = 32
[pid  1379] recvmsg(11, {msg_namelen=0}, 0) = -1 EAGAIN (Ресурс временно недоступен)
[pid  1379] poll([{fd=11, events=POLLIN|POLLOUT}], 1, -1) = 1 ([{fd=11, revents=POLLOUT}])
[pid  1379] writev(11, [{iov_base="\26\2\4\0\1\0`\0\366\0\0\0\305\250\334H\27\0\2\0\366\0\0\0", iov_len=24}, {iov_base=NULL, iov_len=0}, {iov_base="", iov_len=0}], 3) = 24
[pid  1379] poll([{fd=11, events=POLLIN}], 1, -1) = 1 ([{fd=11, revents=POLLIN}])
[pid  1379] recvmsg(11, {msg_name=NULL, msg_namelen=0, msg_iov=[{iov_base="W\0F\0\1\0`\0\1\0`\0\366\0\0\0\306\250\334H\305\250\334H\0\0\0\0\0\0\0\0"..., iov_len=4096}], msg_iovlen=1, msg_controllen=0, msg_flags=0}, 0) = 64
[pid  1379] recvmsg(11, {msg_namelen=0}, 0) = -1 EAGAIN (Ресурс временно недоступен)
[pid  1379] recvmsg(11, {msg_name=NULL, msg_namelen=0, msg_iov=[{iov_base="\36\0G\0\306\250\334H\1\0`\0\n\0 \1\366\0\0\0\372\0\0\0\243\1\0\0\0\0\0\0", iov_len=4096}], msg_iovlen=1, msg_controllen=0, msg_flags=0}, 0) = 32
[pid  1379] recvmsg(11, {msg_namelen=0}, 0) = -1 EAGAIN (Ресурс временно недоступен)
[pid  1379] recvmsg(11, {msg_namelen=0}, 0) = -1 EAGAIN (Ресурс временно недоступен)
[pid  1379] select(11, [10], NULL, NULL, {tv_sec=0, tv_usec=0}) = 0 (Timeout)
[pid  1379] poll([{fd=11, events=POLLIN|POLLOUT}], 1, -1) = 1 ([{fd=11, revents=POLLOUT}])
[pid  1379] writev(11, [{iov_base="\22\0\r\0\n\0 \1\243\1\0\0\4\0\0\0 \0\2\0\7\0\0\0\372\0\0\0\371\0\0\0"..., iov_len=96}, {iov_base=NULL, iov_len=0}, {iov_base="", iov_len=0}], 3) = 96
[pid  1379] recvmsg(11, {msg_namelen=0}, 0) = -1 EAGAIN (Ресурс временно недоступен)
[pid  1379] recvmsg(11, {msg_namelen=0}, 0) = -1 EAGAIN (Ресурс временно недоступен)
[pid  1379] select(14, [13], NULL, NULL, {tv_sec=0, tv_usec=0}) = 0 (Timeout)
[pid  1379] select(15, [14], NULL, NULL, {tv_sec=0, tv_usec=0}) = 0 (Timeout)
[pid  1379] select(16, [15], NULL, NULL, {tv_sec=0, tv_usec=0}) = 0 (Timeout)
[pid  1379] select(16, [4 10 11 12 13 14 15], [], NULL, NULL) = 1 (in [11])
[pid  1379] select(5, [4], NULL, NULL, {tv_sec=0, tv_usec=0}) = 0 (Timeout)
[pid  1379] select(13, [12], NULL, NULL, {tv_sec=0, tv_usec=0}) = 0 (Timeout)
[pid  1379] select(11, [10], NULL, NULL, {tv_sec=0, tv_usec=0}) = 0 (Timeout)
[pid  1379] recvmsg(11, {msg_name=NULL, msg_namelen=0, msg_iov=[{iov_base="\36\0I\0\306\250\334H\1\0`\0\n\0 \1\366\0\0\0\376\0\0\0\243\1\0\0\0\0\0\0", iov_len=4096}], msg_iovlen=1, msg_controllen=0, msg_flags=0}, 0) = 32
[pid  1379] recvmsg(11, {msg_namelen=0}, 0) = -1 EAGAIN (Ресурс временно недоступен)
[pid  1379] select(13, NULL, [12], NULL, {tv_sec=0, tv_usec=0}) = 1 (out [12], left {tv_sec=0, tv_usec=0})
[pid  1379] sendto(12, "\0\0\0\0*\0\0\0\10\0\0\0\"\0\0\0\2\0\3\0\20\0\20\0\0\0\4\0\0\0\4\0"..., 42, 0, NULL, 0) = 42
[pid  1379] recvmsg(11, {msg_namelen=0}, 0) = -1 EAGAIN (Ресурс временно недоступен)
[pid  1379] select(14, [13], NULL, NULL, {tv_sec=0, tv_usec=0}) = 0 (Timeout)
[pid  1379] select(15, [14], NULL, NULL, {tv_sec=0, tv_usec=0}) = 0 (Timeout)
[pid  1379] select(16, [15], NULL, NULL, {tv_sec=0, tv_usec=0}) = 0 (Timeout)
[pid  1379] select(16, [4 10 11 12 13 14 15], [], NULL, NULL) = 1 (in [12])
[pid  1379] select(5, [4], NULL, NULL, {tv_sec=0, tv_usec=0}) = 0 (Timeout)
[pid  1379] select(13, [12], NULL, NULL, {tv_sec=0, tv_usec=0}) = 1 (in [12], left {tv_sec=0, tv_usec=0})
[pid  1379] recvfrom(12, "\0\0\0\0v\2\0\0", 8, 0, NULL, NULL) = 8
[pid  1379] stat("/etc/localtime", {st_mode=S_IFREG|0644, st_size=1535, ...}) = 0
[pid  1379] recvfrom(12, "\5\0\0\0n\2\0\0\2\0\23\0\\\2\\\2\0\0\5\0\1\0T\2\0\0\1\0\0\0d@"..., 622, 0, NULL, NULL) = 622
[pid  1379] stat("/etc/localtime", {st_mode=S_IFREG|0644, st_size=1535, ...}) = 0
[pid  1379] mmap(NULL, 1052672, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7f2b4aa5d000
[pid  1379] --- SIGSEGV {si_signo=SIGSEGV, si_code=SEGV_MAPERR, si_addr=0x10} ---
[pid  1379] write(1, "chansrv::main: using log file [/"..., 2722) = 2722
[pid  1379] exit_group(0)               = ?
[pid  1379] +++ exited with 0 +++
<... select resumed> <unfinished ...>)  = ?
+++ exited with 0 +++

It does not occurred during installation on a regular server (Ubuntu 20.04).

I use xrdp 0.9.13.1 build from source on separate image and copied from it to target.

Environment:

• docker: 19.03.12
• docker host: Debian 10
• image: ubuntu:20.04
• xrdp: 0.9.13.1(from source in )
• xorgxrdp: from source devel branch

Also I can't to make a build of latest devel branch of xrdp. It fails on:

log.c: In function 'log_message':
log.c:558:30: error: '%.2d' directive output may be truncated writing between 2 and 11 bytes into a region of size between 9 and 16 [-Werror=format-truncation=]
  558 |     snprintf(buff, 21, "[%.4d%.2d%.2d-%.2d:%.2d:%.2d] ", now->tm_year + 1900,
      |                              ^~~~
log.c:558:24: note: directive argument in the range [-2147483647, 2147483647]
  558 |     snprintf(buff, 21, "[%.4d%.2d%.2d-%.2d:%.2d:%.2d] ", now->tm_year + 1900,
      |                        ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
In file included from /usr/include/stdio.h:867,
                 from log.c:28:
/usr/include/x86_64-linux-gnu/bits/stdio2.h:67:10: note: '__builtin___snprintf_chk' output between 21 and 73 bytes into a destination of size 21
   67 |   return __builtin___snprintf_chk (__s, __n, __USE_FORTIFY_LEVEL - 1,
      |          ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
   68 |        __bos (__s), __fmt, __va_arg_pack ());
      |        ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
cc1: all warnings being treated as errors
make[2]: *** [Makefile:548: log.lo] Error 1
make[2]: Leaving directory '/src/xrdp/common'
make[1]: Leaving directory '/src/xrdp'
make[1]: *** [Makefile:482: all-recursive] Error 1
make: *** [Makefile:414: all] Error 2
The command '/bin/sh -c cd ./xrdp &&     ./bootstrap &&     ./configure         --enable-jpeg         --enable-fuse         --enable-rfxcodec         --enable-opus         --enable-painter         --enable-vsock         --enable-mp3lame         --enable-pixman         --prefix=/usr         --includedir=${prefix}/include         --mandir=${prefix}/share/man         --infodir=${prefix}/share/info         --sysconfdir=/etc         --localstatedir=/var         --disable-silent-rules         --libdir=${prefix}/lib/x86_64-linux-gnu         --libexecdir=${prefix}/lib/x86_64-linux-gnu         --disable-maintainer-mode         --disable-dependency-tracking         --with-socketdir=/run/xrdp/sockdir &&     make &&     make DESTDIR="${PKG_DIR}" install &&     cd ..' returned a non-zero code: 2
ERROR: Job failed: exit status 1

Those warnings also appears on build 0.9.13.1, but not stops it.

[endofreal]

I fixed xrdp-chansrv fails.
File transfer (as a drive redirection) use fuse file system. When you starts the container you must to redirect device /dev/fuse into it.

But it's not normal, that xrdp-chansrv fail without any messages in the log.

[matt335672]

I was just replying to you and got called away. Glad you found the problem.

Chansrv writes quite a bit of information to stdout, so there might be some useful information somewhere in your container. You can possibly track this down by issuing ls -l /proc/<chansrv.pid>/fdwhile chansrv is running to see where this is going.

As regards your compiler errors, there's clearly something here that needs looking into which I will do. The reason that the error is fatal on the devel wavefront is that the compilation on Linux now happens with -Werror. That's down to the following two lines added to configure.ac:-

AM_COND_IF([LINUX],
  [AX_APPEND_COMPILE_FLAGS([-Werror])]) # bsd has warnings that have not been fixed yet

In the short term if you remove these lines you'll be able to build the devel version of you want to.

[endofreal]

Thanks for quick response!

Chansrv writes quite a bit of information to stdout, so there might be some useful information somewhere in your container. You can possibly track this down by issuing ls -l /proc/<chansrv.pid>/fdwhile chansrv is running to see where this is going.

What do you mean? In /proc/<chansrv.pid>/fd I see symbol links. One of them point to xrdp-chansrv log file, other on pipes and sockets. But nothing changes in log file when process crashed and became zombie.

As regards your compiler errors, there's clearly something here that needs looking into which I will do. The reason that the error is fatal on the devel wavefront is that the compilation on Linux now happens with -Werror. That's down to the following two lines added to configure.ac:-

I thought so. Additional thanks for quick fix it!

[matt335672]

OK - thanks for the feedback about the log. It sounds like stdout is not being flushed before the SEGV.

I'll try to reproduce it and come up with a fix for it so we can close this.

[matt335672]

Hi @endofreal

I'm having problems reproducing your crash.

I'm on a standard Ubuntu 18.04 install logged in from Windows 10 and I've removed /dev/fuse to try to reproduce your environment.

I'm getting plenty of errors but no crashes.

Could you be a bit more specific about how you cause the crash to happen? What exactly do you mean by 'click copy file' on the Windows 10 machine.

Thanks for any info

[endofreal]

Hi @matt335672

Maybe you can not reproduce it because by default docker has no privileges to write into /dev/fuse.

Step to reproduce xrdp-chansrv crash on Ubuntu 20.04 (same on 20.10):

chmod 000 /dev/fuse

# connect to XRDP
ls -la /proc/`pgrep xrdp-chansrv`/fd
# total 0
# lrwx------ 1 someuser someuser 64 авг 24 08:38 0 -> /dev/null
# lrwx------ 1 someuser someuser 64 авг 24 08:38 1 -> /dev/null
# lrwx------ 1 someuser someuser 64 авг 24 08:38 10 -> 'socket:[45337]'
# lrwx------ 1 someuser someuser 64 авг 24 08:38 11 -> /dev/fuse
# lrwx------ 1 someuser someuser 64 авг 24 08:38 12 -> 'socket:[45343]'
# lrwx------ 1 someuser someuser 64 авг 24 08:38 13 -> 'socket:[45357]'
# lrwx------ 1 someuser someuser 64 авг 24 08:38 14 -> 'socket:[45379]'
# lrwx------ 1 someuser someuser 64 авг 24 08:38 15 -> 'socket:[45380]'
# lrwx------ 1 someuser someuser 64 авг 24 08:38 16 -> 'socket:[46331]'
# lrwx------ 1 someuser someuser 64 авг 24 08:38 2 -> /dev/null
# l-wx------ 1 someuser someuser 64 авг 24 08:38 3 -> /home/someuser/.local/share/xrdp/xrdp-chansrv.10.log
# lr-x------ 1 someuser someuser 64 авг 24 08:38 4 -> 'pipe:[45334]'
# l-wx------ 1 someuser someuser 64 авг 24 08:38 5 -> 'pipe:[45334]'
# lr-x------ 1 someuser someuser 64 авг 24 08:38 6 -> 'pipe:[45335]'
# l-wx------ 1 someuser someuser 64 авг 24 08:38 7 -> 'pipe:[45335]'
# lr-x------ 1 someuser someuser 64 авг 24 08:38 8 -> 'pipe:[45336]'
# l-wx------ 1 someuser someuser 64 авг 24 08:38 9 -> 'pipe:[45336]'

# RMB on testfile.exe and click Copy
ps auxf | grep xrdp-chansrv
# someuser 13274 0.0  0.0      0     0 ?        Z    08:29   0:00      \_ [xrdp-chansrv] <defunct>
cat /home/someuser/.local/share/xrdp/xrdp-chansrv.10.log
# [20200824-08:38:06] [CORE ] main: app started pid 13274(0x000033da)
# [20200824-08:38:06] [INFO ] main: DISPLAY env var set to :10.0
# [20200824-08:38:06] [INFO ] main: using DISPLAY 10
# [20200824-08:38:06] [INFO ] channel_thread_loop: thread start
# [20200824-08:38:06] [INFO ] Socket 12: AF_UNIX connection received

[matt335672]

I still can't reproduce this using the above, on either 18.04 or 20.04.

I'm not clear from your description whether the chmod 000 /dev/fuse is entered before or after the session is created. Neither lets me reproduce it.

If I enter the chmod 000 /dev/fuse before the session is created, chansrv simply refuses to connect to /dev/fuse. So I don't get file descriptor 11 connected to /dev/fuse at all.

If I enter the chmod 000 /dev/fuse after the session is created, chansrv is already connected to /dev/fuse and everything works as normal.

It looks like something else is going on here.

Have you actually reproduce this on a standard install (i.e. not using Docker)? If so we can install a debugger and some debugging symbols and get a stck trace out of chansrv. I can walk you through that.

[endofreal]

In this case I had not used docker. It standalone installation where I had tried to reproduce xrdp-chansrv crashes and I had it.

XRDP services were in started state. I denied any access to /dev/fuse with chmod 000 /dev/fuse.
I had start the connection and try to copy file, after that xrdp-chansrv became defunt as I wrote early.

Maybe it's really environment problem, so than the issue may be closed. Or if you would like I can to collect some additional info?

[matt335672]

I'd like to find this if possible, and if you're willing to help. We'll need to install a debugger to do it.

I'm out of time today so I'll post more info tomorrow. Are you running xrdp from source or from APT?

Thanks

[endofreal]

I want to help this project if I can!

I running xrdp from sources build from 0.9.13.1 tag.

I'll waiting instructions how to debug this.

[matt335672]

If you're running from source it's a lot easier as you'll already have debug symbols available. It makes it easier for us to try a patch if we get that far.

Instructions are:-

• Install the gdb debugger:-
  sudo apt install gdb
• Log a session in over XRDP.
• From another session, connect gdb to xrdp-chansrv with
  sudo gdb -p $(pgrep xrdp-chansrv)
  Enter the cont command to get the debugger to continue.
• RMB on testfile.exe and click Copy. xrdp-chansrv should stop when it gets the SEGV
• Enter the where command at the gdb prompt and post the results here.

Thanks for your help with this.

[endofreal]

Result:

Attaching to process 188746
[New LWP 188750]
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
0x00007fd52831af9b in __GI___select (nfds=9, readfds=0x7ffd95698750, writefds=0x7ffd956987d0, exceptfds=exceptfds@entry=0x0,
    timeout=timeout@entry=0x0) at ../sysdeps/unix/sysv/linux/select.c:41
41      ../sysdeps/unix/sysv/linux/select.c: No such file or directory.
(gdb) cont
Continuing.

Thread 2 "xrdp-chansrv" received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0x7fd5277b3700 (LWP 188750)]
xfs_add_entry (xfs=0x0, parent_inum=0, name=name@entry=0x7fd5200320c8 "testfile.exe", mode=mode@entry=33206) at chansrv_xfs.c:424
424     chansrv_xfs.c: No such file or directory.
(gdb) where
#0  xfs_add_entry (xfs=0x0, parent_inum=0, name=name@entry=0x7fd5200320c8 "testfile.exe", mode=mode@entry=33206) at chansrv_xfs.c:424
#1  0x000055bf159437f6 in xfuse_add_clip_dir_item (filename=filename@entry=0x7fd5200320c8 "testfile.exe", flags=flags@entry=0,
    size=11161560, lindex=lindex@entry=0) at chansrv_fuse.c:742
#2  0x000055bf15949019 in clipboard_c2s_in_files (s=s@entry=0x7fd520015640, file_list=<optimized out>) at clipboard_file.c:668
#3  0x000055bf1594740c in clipboard_process_data_response (clip_msg_status=<optimized out>, clip_msg_len=<optimized out>, s=0x7fd520015640)
    at clipboard.c:1280
#4  clipboard_data_in (s=<optimized out>, chan_id=<optimized out>, chan_flags=<optimized out>, length=<optimized out>,
    total_length=<optimized out>) at clipboard.c:1658
#5  0x000055bf1594005e in process_message_channel_data (s=0x7fd520015640) at chansrv.c:453
#6  process_message () at chansrv.c:858
#7  my_trans_data_in (trans=<optimized out>) at chansrv.c:917
#8  my_trans_data_in (trans=<optimized out>) at chansrv.c:892
#9  0x00007fd5286a26e2 in trans_check_wait_objs (self=0x7fd520015390) at trans.c:426
#10 0x000055bf1594095b in channel_thread_loop (in_val=<optimized out>) at chansrv.c:1431
#11 0x00007fd5283fe609 in start_thread (arg=<optimized out>) at pthread_create.c:477
#12 0x00007fd528325103 in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:95
(gdb)

By the way I'm not using xfs filesystem. All volumes on server in ext4.

[matt335672]

Well, that's really interesting - thanks.

The xfs referred to above is XRDP filesystem. It's used to map the Windows file data to UNIX file data on our side when we're using drive redirection. I'm responsible for the name, and I admit that you're quite right - it wasn't perhaps the best choice.

The clipboard data is calling into the code when XFS is not initialised (xfs=0x0) and that's guaranteed to bring down chansrv. I can't see why I'm not getting a coredump on my system, but there's an easy enough fix for it.

I've just pushed a branch issue1658-2 to my git repo. The actual patch is at the end of this message if you'd rather use that. It should fix the crash you're seeing.

Would you be able to try that for me?

These corner-case bugs are really hard to track down as they affect so few users. Thanks again for your help with this.

--- a/sesman/chansrv/chansrv_fuse.c
+++ b/sesman/chansrv/chansrv_fuse.c
@@ -738,20 +738,32 @@ xfuse_add_clip_dir_item(const char *filename, int flags, int size, int lindex)
     log_debug("entered: filename=%s flags=%d size=%d lindex=%d",
               filename, flags, size, lindex);

-    /* add entry to xrdp_fs */
-    XFS_INODE *xinode = xfs_add_entry( g_xfs,
-                                       g_clipboard_inum,    /* parent inode */
-                                       filename,
-                                       (0666 | S_IFREG));
-    if (xinode == NULL)
-    {
-        log_debug("failed to create file in xrdp filesystem");
-        return -1;
+    int result = -1;
+
+    if (g_xfs == NULL)
+    {
+        log_debug("xfuse_add_clip_dir_item() called with no filesystem")
+    }
+    else
+    {
+        /* add entry to xrdp_fs */
+        XFS_INODE *xinode = xfs_add_entry( g_xfs,
+                                           g_clipboard_inum, /* parent inode */
+                                           filename,
+                                           (0666 | S_IFREG));
+        if (xinode == NULL)
+        {
+            log_debug("failed to create file in xrdp filesystem");
+        }
+        else
+        {
+            xinode->size = size;
+            xinode->lindex = lindex;
+            result = 0;
+        }
     }
-    xinode->size = size;
-    xinode->lindex = lindex;

-    return 0;
+    return result;
 }

 /**

[cyrus-and]

I was about to file a new issue then I found this one, I'm not sure if it's the same problem and solution so I'll post a quick way to reproduce it here. Please let me know if I should open a new issue.

---

1. mkdir xrdp-issue.

2. Create a Dockerfile as follows:

FROM ubuntu:20.04

ARG DEBIAN_FRONTEND=noninteractive

RUN : \
    && apt-get update \
    && apt-get -y upgrade \
    && apt-get -y install xubuntu-default-settings xrdp

# Disabling channels *fixes* the problem
# RUN sed -i 's/allow_channels=true/allow_channels=false/' /etc/xrdp/xrdp.ini

RUN : \
    && useradd -ms /bin/bash user \
    && echo 'user:pass' | chpasswd \
    && echo 'exec xfce4-session' >~user/.xsession

CMD /etc/init.d/xrdp start && bash

1. docker build --tag xrdp-issue .

2. docker run --rm -it -p 3389:3389 xrdp-issue

3. In a new terminal run rdesktop -u user -p pass localhost

4. Wait for the desktop to properly load and show up.

5. In the container shell run the following to check that xrdp-chansrv is running:

root@05b609965d88:/# ps aux | grep xrdp-chansrv
user        46  0.0  0.1  86516  3128 pts/0    Sl   11:42   0:00 /usr/sbin/xrdp-chansrv

1. Close the rdesktop window and run rdesktop -u user -p pass localhost again. The desktop should pop up immediately instead it takes several seconds. The time is likely to be spent here:

https://github.com/neutrinolabs/xrdp/blob/0a669c5b06c120ea105a95d74807c45067f05206/xrdp/xrdp_mm.c#L1462-L1477

1. After that, in the container shell we can see that the xrdp-charsrv process is defunct and not restarted. And channels stop working.

root@05b609965d88:/# ps aux | grep xrdp-chansrv
user        46  0.0  0.0      0     0 pts/0    Z    11:42   0:00 [xrdp-chansrv] <defunct>

1. Manually starting xrdp-chansrv seems to work, but at the next reconnection it fails with:

root@05b609965d88:/# DISPLAY=:10.0 xrdp-chansrv
chansrv::main: using log file [/root/.local/share/xrdp/xrdp-chansrv.10.log]
[20200826-11:49:57] [CORE ] main: app started pid 292(0x00000124)
[20200826-11:49:57] [INFO ] main: DISPLAY env var set to :10.0
[20200826-11:49:57] [INFO ] main: using DISPLAY 10
[20200826-11:49:57] [INFO ] channel_thread_loop: thread start

xrdp-sesman[29]: (29)(140142428034624)[INFO ] A connection received from ::ffff:127.0.0.1 port 42726

xrdp-sesman[29]: pam_unix(xrdp-sesman:auth): Couldn't open /etc/securetty: No such file or directory
xrdp-sesman[29]: pam_unix(xrdp-sesman:auth): Couldn't open /etc/securetty: No such file or directory
xrdp-sesman[29]: (29)(140142428034624)[INFO ] ++ reconnected session: username user, display :10.0, session_pid 41, ip ::ffff:172.17.0.1:37906 - socket: 11

xrdp-sesman[29]: (29)(140142428034624)[DEBUG] Closed socket 7 (AF_INET6 ::ffff:127.0.0.1 port 3350)

[20200826-11:50:07] [INFO ] Socket 12: AF_UNIX connection received
process_message_channel_setup: chan name 'cliprdr' id 0 flags 0000a0c0
process_message_channel_setup: chan name 'rdpsnd' id 1 flags 000000c0
process_message_channel_setup: chan name 'snddbg' id 2 flags 000000c0
process_message_channel_setup: chan name 'rdpdr' id 3 flags 00008080
process_message_channel_setup: chan name 'drdynvc' id 4 flags 000000c0
fuse: device not found, try 'modprobe fuse' first
[0714773461]: FUSE       xfuse_init_lib: 790 : ERROR: fuse_mount() failed
No protocol specified
[20200826-11:50:07] [ERROR] xcommon_init: error, XOpenDisplay failed
xrdp-chansrv [0714773466]: segfault_signal_handler: entered.......
Segmentation fault

Note:

• I need channels for the clipboard only.
• The first time it works.
• I need to run this in a non-privileged Docker container.

[endofreal]

@cyrus-and

It fixed in 0.9.13 release. Ubuntu repository has just 0.9.12.
The solution is install xrdp from sources or download compiled package from releases.

[cyrus-and]

@endofreal thanks for the timely reply! But where are the compiled packages? I can only find source code archives in the release page.

[endofreal]

@cyrus-and sorry! I build it from sources and do not download release archive to know what in it =)
Your only way to build it. Example code is (build dependencies is redundant I know):

FROM ubuntu:20.04 as builder

# Install build dependencies
ARG DEBIAN_FRONTEND=noninteractive
RUN apt-get update -y && apt-get upgrade -y && apt-get install -y \
    asciidoctor autoconf autopoint bison clang flex g++ gcc gettext git intltool \
    libfuse-dev libgdk-pixbuf2.0-dev libjpeg-dev libmp3lame-dev libopus-dev \
    libpam0g-dev libpixman-1-dev libssl-dev libtool libx11-dev \
    libxcomposite-dev libxdamage-dev libxfixes-dev libxft-dev \
    libxinerama-dev libxml2-dev libxpm-dev libxrandr-dev \
    locales m4 make nasm pkg-config python-libxml2 xserver-xorg-dev xsltproc xutils xutils-dev

# Get source code
WORKDIR /src
RUN git clone --recursive https://github.com/neutrinolabs/xrdp.git
RUN git clone --recursive https://github.com/neutrinolabs/xorgxrdp.git

# Build packages
RUN mkdir /packages
RUN cd ./xrdp && git checkout v0.9.13.1 && \
    ./bootstrap && \
    ./configure \
        --enable-jpeg \
        --enable-fuse \
        --enable-rfxcodec \
        --enable-opus \
        --enable-painter \
        --enable-vsock \
        --enable-mp3lame \
        --enable-pixman  && \
    make && make DESTDIR=/packages install
RUN cd ./xorgxrdp && \
    ./bootstrap && \
    ./configure XRDP_CFLAGS=-I/src/xrdp/common && \
    make && make DESTDIR=/packages install

FROM ubuntu:20.04
...
COPY --from=builder /packages /
RUN sed -i 's|param=Xorg|param=/usr/lib/xorg/Xorg|g' /etc/xrdp/sesman.ini
...

[cyrus-and]

Awesome, thank you @endofreal!

[endofreal]

@cyrus-and you are welcome!

And I forgot! You must also replace one param in sesman.ini

RUN sed -i 's|param=Xorg|param=/usr/lib/xorg/Xorg|g' /etc/xrdp/sesman.ini

[cyrus-and]

@endofreal

And I forgot! You must also replace one param in sesman.ini

That was exactly the Issue I've been facing... :) Not it starts but the defunct issue persists unfortunately.

[cyrus-and]

Alright the "solution" was to disable the FUSE support at compile time by removing --enable-fuse. I still think this is a bug...

[endofreal]

When you reconnect to the session?

Are you sure what you do not install ubuntu xrdp package or some other?
In my case xrdp-chansrv crashes when reconnecting stops on v0.9.13.1.

[cyrus-and]

When you reconnect to the session?

Yes when I kill rdesktop and reopen it.

Are you sure what you do not install ubuntu xrdp package or some other?

100%.

Well I don't need FUSE anyway, so it's not a big deal for me.

[endofreal]

@matt335672

Emm... Maybe it's environment problem (I build branch issue1658-2 it on the same machine), but after connect now I see the codec glitch:

I can not reproduce xrdp-chansrv crashes on it.
I've added CHANSRV_LOG_LEVEL=LOG_LEVEL_DEBUG into /etc/xrdp/sesman.ini and deny any access to the /dev/fuse, connect to session and copy file, but nothing happens (xrdp-chansrv still alive).
In the log file I see nothing useful:

[20200826-14:21:54] [CORE ] main: app started pid 2274(0x000008e2)
[20200826-14:21:54] [INFO ] main: DISPLAY env var set to :10.0
[20200826-14:21:54] [INFO ] main: using DISPLAY 10
[20200826-14:21:54] [INFO ] channel_thread_loop: thread start
[20200826-14:21:54] [INFO ] Socket 12: AF_UNIX connection received
[20200826-14:21:54] [DEBUG] my_trans_conn_in:
[20200826-14:21:54] [DEBUG] Closed socket 11 (AF_UNIX)
[20200826-14:21:54] [DEBUG] my_trans_data_in:
[20200826-14:21:54] [DEBUG] process_message_channel_setup:
[20200826-14:21:54] [DEBUG] process_message_channel_setup: num_chans 4
[20200826-14:21:54] [DEBUG] process_message_channel_setup: chan name 'rdpdr' id 0 flags 00000000
[20200826-14:21:54] [DEBUG] process_message_channel_setup: chan name 'rdpsnd' id 1 flags 00000000
[20200826-14:21:54] [DEBUG] process_message_channel_setup: chan name 'cliprdr' id 2 flags 00000000
[20200826-14:21:54] [DEBUG] process_message_channel_setup: chan name 'drdynvc' id 3 flags 00000000
[20200826-14:21:55] [DEBUG] my_trans_data_in:
[20200826-14:21:55] [DEBUG] process_message_channel_data: chan_id 1 chan_flags 3
[20200826-14:21:55] [DEBUG] my_trans_data_in:
[20200826-14:21:55] [DEBUG] process_message_channel_data: chan_id 0 chan_flags 3
[20200826-14:21:55] [DEBUG] my_trans_data_in:
[20200826-14:21:55] [DEBUG] process_message_channel_data: chan_id 0 chan_flags 3
[20200826-14:21:55] [DEBUG] my_trans_data_in:
[20200826-14:21:55] [DEBUG] process_message_channel_data: chan_id 2 chan_flags 19
[20200826-14:21:55] [DEBUG] my_trans_data_in:
[20200826-14:21:55] [DEBUG] process_message_channel_data: chan_id 2 chan_flags 19
[20200826-14:21:55] [DEBUG] my_trans_data_in:
[20200826-14:21:55] [DEBUG] process_message_channel_data: chan_id 1 chan_flags 3
[20200826-14:21:55] [DEBUG] my_trans_data_in:
[20200826-14:21:55] [DEBUG] process_message_channel_data: chan_id 0 chan_flags 3
[20200826-14:21:55] [DEBUG] my_trans_data_in:
[20200826-14:21:55] [DEBUG] process_message_channel_data: chan_id 0 chan_flags 1
[20200826-14:21:55] [DEBUG] my_trans_data_in:
[20200826-14:21:55] [DEBUG] process_message_channel_data: chan_id 0 chan_flags 0
[20200826-14:21:55] [DEBUG] my_trans_data_in:
[20200826-14:21:55] [DEBUG] process_message_channel_data: chan_id 0 chan_flags 0
[20200826-14:21:55] [DEBUG] my_trans_data_in:
[20200826-14:21:55] [DEBUG] process_message_channel_data: chan_id 0 chan_flags 0
[20200826-14:21:55] [DEBUG] my_trans_data_in:
[20200826-14:21:55] [DEBUG] process_message_channel_data: chan_id 0 chan_flags 0
[20200826-14:21:55] [DEBUG] my_trans_data_in:
[20200826-14:21:55] [DEBUG] process_message_channel_data: chan_id 0 chan_flags 0
[20200826-14:21:55] [DEBUG] my_trans_data_in:
[20200826-14:21:55] [DEBUG] process_message_channel_data: chan_id 0 chan_flags 0
[20200826-14:21:55] [DEBUG] my_trans_data_in:
[20200826-14:21:55] [DEBUG] process_message_channel_data: chan_id 0 chan_flags 0
[20200826-14:21:55] [DEBUG] my_trans_data_in:
[20200826-14:21:55] [DEBUG] process_message_channel_data: chan_id 0 chan_flags 0
[20200826-14:21:55] [DEBUG] my_trans_data_in:
[20200826-14:21:55] [DEBUG] process_message_channel_data: chan_id 0 chan_flags 0
[20200826-14:21:55] [DEBUG] my_trans_data_in:
[20200826-14:21:55] [DEBUG] process_message_channel_data: chan_id 0 chan_flags 0
[20200826-14:21:55] [DEBUG] my_trans_data_in:
[20200826-14:21:55] [DEBUG] process_message_channel_data: chan_id 0 chan_flags 0
[20200826-14:21:55] [DEBUG] my_trans_data_in:
[20200826-14:21:55] [DEBUG] process_message_channel_data: chan_id 0 chan_flags 0
[20200826-14:21:55] [DEBUG] my_trans_data_in:
[20200826-14:21:55] [DEBUG] process_message_channel_data: chan_id 0 chan_flags 0
[20200826-14:21:55] [DEBUG] my_trans_data_in:
[20200826-14:21:55] [DEBUG] process_message_channel_data: chan_id 0 chan_flags 0
[20200826-14:21:55] [DEBUG] my_trans_data_in:
[20200826-14:21:55] [DEBUG] process_message_channel_data: chan_id 0 chan_flags 0
[20200826-14:21:55] [DEBUG] my_trans_data_in:
[20200826-14:21:55] [DEBUG] process_message_channel_data: chan_id 0 chan_flags 0
[20200826-14:21:55] [DEBUG] my_trans_data_in:
[20200826-14:21:55] [DEBUG] process_message_channel_data: chan_id 0 chan_flags 0
[20200826-14:21:55] [DEBUG] my_trans_data_in:
[20200826-14:21:55] [DEBUG] process_message_channel_data: chan_id 0 chan_flags 0
[20200826-14:21:55] [DEBUG] my_trans_data_in:
[20200826-14:21:55] [DEBUG] process_message_channel_data: chan_id 0 chan_flags 0
[20200826-14:21:55] [DEBUG] my_trans_data_in:
[20200826-14:21:55] [DEBUG] process_message_channel_data: chan_id 0 chan_flags 0
[20200826-14:21:55] [DEBUG] my_trans_data_in:
[20200826-14:21:55] [DEBUG] process_message_channel_data: chan_id 0 chan_flags 0
[20200826-14:21:55] [DEBUG] my_trans_data_in:
[20200826-14:21:55] [DEBUG] process_message_channel_data: chan_id 0 chan_flags 0
[20200826-14:21:55] [DEBUG] my_trans_data_in:
[20200826-14:21:55] [DEBUG] process_message_channel_data: chan_id 0 chan_flags 0
[20200826-14:21:55] [DEBUG] my_trans_data_in:
[20200826-14:21:55] [DEBUG] process_message_channel_data: chan_id 0 chan_flags 0
[20200826-14:21:55] [DEBUG] my_trans_data_in:
[20200826-14:21:55] [DEBUG] process_message_channel_data: chan_id 0 chan_flags 0
[20200826-14:21:55] [DEBUG] my_trans_data_in:
[20200826-14:21:55] [DEBUG] process_message_channel_data: chan_id 0 chan_flags 0
[20200826-14:21:55] [DEBUG] my_trans_data_in:
[20200826-14:21:55] [DEBUG] process_message_channel_data: chan_id 0 chan_flags 0
[20200826-14:21:55] [DEBUG] my_trans_data_in:
[20200826-14:21:55] [DEBUG] process_message_channel_data: chan_id 0 chan_flags 0
[20200826-14:21:55] [DEBUG] my_trans_data_in:
[20200826-14:21:55] [DEBUG] process_message_channel_data: chan_id 0 chan_flags 0
[20200826-14:21:55] [DEBUG] my_trans_data_in:
[20200826-14:21:55] [DEBUG] process_message_channel_data: chan_id 0 chan_flags 0
[20200826-14:21:55] [DEBUG] my_trans_data_in:
[20200826-14:21:55] [DEBUG] process_message_channel_data: chan_id 0 chan_flags 0
[20200826-14:21:55] [DEBUG] my_trans_data_in:
[20200826-14:21:55] [DEBUG] process_message_channel_data: chan_id 0 chan_flags 0
[20200826-14:21:55] [DEBUG] my_trans_data_in:
[20200826-14:21:55] [DEBUG] process_message_channel_data: chan_id 0 chan_flags 0
[20200826-14:21:55] [DEBUG] my_trans_data_in:
[20200826-14:21:55] [DEBUG] process_message_channel_data: chan_id 0 chan_flags 2
[20200826-14:21:55] [DEBUG] my_trans_data_in:
[20200826-14:21:55] [DEBUG] process_message_channel_data: chan_id 0 chan_flags 3
[20200826-14:21:55] [DEBUG] my_trans_data_in:
[20200826-14:21:55] [DEBUG] process_message_channel_data: chan_id 0 chan_flags 3
[20200826-14:21:55] [DEBUG] my_trans_data_in:
[20200826-14:21:55] [DEBUG] process_message_channel_data: chan_id 0 chan_flags 3
[20200826-14:22:20] [DEBUG] my_trans_data_in:
[20200826-14:22:20] [DEBUG] process_message_channel_data: chan_id 2 chan_flags 19
[20200826-14:22:20] [DEBUG] my_trans_data_in:
[20200826-14:22:20] [DEBUG] process_message_channel_data: chan_id 2 chan_flags 19
[20200826-14:22:20] [DEBUG] my_trans_data_in:
[20200826-14:22:20] [DEBUG] process_message_channel_data: chan_id 2 chan_flags 19
[20200826-14:23:10] [DEBUG] my_trans_data_in:
[20200826-14:23:10] [DEBUG] process_message_channel_data: chan_id 2 chan_flags 19
[20200826-14:23:10] [DEBUG] my_trans_data_in:
[20200826-14:23:10] [DEBUG] process_message_channel_data: chan_id 2 chan_flags 19
[20200826-14:23:10] [DEBUG] my_trans_data_in:
[20200826-14:23:10] [DEBUG] process_message_channel_data: chan_id 2 chan_flags 19
[20200826-14:23:16] [DEBUG] my_trans_data_in:
[20200826-14:23:16] [DEBUG] process_message_channel_data: chan_id 2 chan_flags 19
[20200826-14:23:16] [DEBUG] my_trans_data_in:
[20200826-14:23:16] [DEBUG] process_message_channel_data: chan_id 2 chan_flags 19
[20200826-14:23:52] [DEBUG] my_trans_data_in:
[20200826-14:23:52] [DEBUG] process_message_channel_data: chan_id 2 chan_flags 19
[20200826-14:23:52] [DEBUG] my_trans_data_in:
[20200826-14:23:52] [DEBUG] process_message_channel_data: chan_id 2 chan_flags 19
[20200826-14:24:03] [DEBUG] my_trans_data_in:
[20200826-14:24:03] [DEBUG] process_message_channel_data: chan_id 2 chan_flags 19
[20200826-14:24:03] [DEBUG] my_trans_data_in:
[20200826-14:24:03] [DEBUG] process_message_channel_data: chan_id 2 chan_flags 19

[matt335672]

Hi @cyrus-and

The 'defunct' issue shouldn't happen, so there's a bug there.

The two likely ones are the one present in v0.9.12, or the one I've posted a patch for above.

You've eliminated the first by following @endofreal very useful instructions to get the v0.9.13.1 version down.

@endofreal doesn't include the instructions for applying the patch I've posted above. Did you try that?

Thanks

[matt335672]

Hi @endofreal

I've not come across the 'codec glitch' you mention. Is it referenced or described elsewhere?

Thanks,

[endofreal]

@matt335672

I'll try tomorrow to make a build on clear system to exclude environment problems and report to you.

[endofreal]

@matt335672

I've made a clear build in docker image from your issue1658-2 branch and ran it without /dev/fuse (also tried without privileges to access result the same).

xrdp-chansrv process now isn't craches when file copy, but it's nothing write into log file (~/.local/share/xrdp/xrdp-chansrv.10.log or any else):

[20200827-10:20:16] [CORE ] main: app started pid 314(0x0000013a)
[20200827-10:20:16] [INFO ] main: DISPLAY env var set to :10.0
[20200827-10:20:16] [INFO ] main: using DISPLAY 10
[20200827-10:20:16] [INFO ] channel_thread_loop: thread start
[20200827-10:20:16] [INFO ] Socket 12: AF_UNIX connection received
[20200827-10:20:16] [DEBUG] my_trans_conn_in:
[20200827-10:20:16] [DEBUG] Closed socket 11 (AF_UNIX)
[20200827-10:20:16] [DEBUG] my_trans_data_in:
[20200827-10:20:16] [DEBUG] process_message_channel_setup:
[20200827-10:20:16] [DEBUG] process_message_channel_setup: num_chans 4
[20200827-10:20:16] [DEBUG] process_message_channel_setup: chan name 'rdpdr' id 0 flags 00000000
[20200827-10:20:16] [DEBUG] process_message_channel_setup: chan name 'rdpsnd' id 1 flags 00000000
[20200827-10:20:16] [DEBUG] process_message_channel_setup: chan name 'cliprdr' id 2 flags 00000000
[20200827-10:20:16] [DEBUG] process_message_channel_setup: chan name 'drdynvc' id 3 flags 00000000
[20200827-10:20:17] [DEBUG] my_trans_data_in:
[20200827-10:20:17] [DEBUG] process_message_channel_data: chan_id 2 chan_flags 19
[20200827-10:20:17] [DEBUG] my_trans_data_in:
[20200827-10:20:17] [DEBUG] process_message_channel_data: chan_id 2 chan_flags 19
[20200827-10:20:17] [DEBUG] my_trans_data_in:
[20200827-10:20:17] [DEBUG] process_message_channel_data: chan_id 1 chan_flags 3
[20200827-10:20:17] [DEBUG] my_trans_data_in:
[20200827-10:20:17] [DEBUG] process_message_channel_data: chan_id 0 chan_flags 3
[20200827-10:20:17] [DEBUG] my_trans_data_in:
[20200827-10:20:17] [DEBUG] process_message_channel_data: chan_id 0 chan_flags 3
[20200827-10:20:17] [DEBUG] my_trans_data_in:
[20200827-10:20:17] [DEBUG] process_message_channel_data: chan_id 1 chan_flags 3
[20200827-10:20:17] [DEBUG] my_trans_data_in:
[20200827-10:20:17] [DEBUG] process_message_channel_data: chan_id 0 chan_flags 3
[20200827-10:20:17] [DEBUG] my_trans_data_in:
[20200827-10:20:17] [DEBUG] process_message_channel_data: chan_id 0 chan_flags 1
[20200827-10:20:17] [DEBUG] my_trans_data_in:
[20200827-10:20:17] [DEBUG] process_message_channel_data: chan_id 0 chan_flags 0
[20200827-10:20:17] [DEBUG] my_trans_data_in:
[20200827-10:20:17] [DEBUG] process_message_channel_data: chan_id 0 chan_flags 0
...

But in the stdout I see some messages like (many processes output their log in the stdout and it hard to get chansrv messages):

xrdp_wm_init: channel drdynvc channel id 3 chansrv::main: using log file [/home/someuser/.local/share/xrdp/xrdp-chansrv.10.log]
[20200827-10:20:16] [CORE ] main: app started pid 314(0x0000013a)
[20200827-10:20:16] [INFO ] main: DISPLAY env var set to :10.0
[20200827-10:20:16] [INFO ] main: using DISPLAY 10
[20200827-10:20:16] [INFO ] channel_thread_loop: thread start
[20200827-10:20:16] [INFO ] Socket 12: AF_UNIX connection received
[20200827-10:20:16] [DEBUG] my_trans_conn_in:
[20200827-10:20:16] [DEBUG] Closed socket 11 (AF_UNIX)
[20200827-10:20:16] [DEBUG] my_trans_data_in:
[20200827-10:20:16] [DEBUG] process_message_channel_setup:
[20200827-10:20:16] [DEBUG] process_message_channel_setup: num_chans 4
[20200827-10:20:16] [DEBUG] process_message_channel_setup: chan name 'rdpdr' id 0 flags 00000000
process_message_channel_setup: chan name 'rdpdr' id 0 flags 00000000
[20200827-10:20:16] [DEBUG] process_message_channel_setup: chan name 'rdpsnd' id 1 flags 00000000
process_message_channel_setup: chan name 'rdpsnd' id 1 flags 00000000
[20200827-10:20:16] [DEBUG] process_message_channel_setup: chan name 'cliprdr' id 2 flags 00000000
process_message_channel_setup: chan name 'cliprdr' id 2 flags 00000000
[20200827-10:20:16] [DEBUG] process_message_channel_setup: chan name 'drdynvc' id 3 flags 00000000
process_message_channel_setup: chan name 'drdynvc' id 3 flags 00000000
[0784982756]: FUSE       xfuse_init_lib: 804 : ERROR: fuse_mount() failed
xrdp-chansrv [0784982913]: xcommon_init: connected to display ok
[0784982914]: FUSE       xfuse_init_lib: 804 : ERROR: fuse_mount() failed
xrdp-chansrv [0784982914]: sound_init:
[0784982915]: FUSE       xfuse_init_lib: 804 : ERROR: fuse_mount() failed
xrdp-chansrv [0784982915]: audin_init:
xrdp-chansrv [0784982965]: sound_process_output_format:
xrdp-chansrv [0784982965]:       wFormatTag      1
xrdp-chansrv [0784982965]:       nChannels       2
xrdp-chansrv [0784982965]:       nSamplesPerSec  44100
xrdp-chansrv [0784982965]:       nAvgBytesPerSec 176400
xrdp-chansrv [0784982965]:       nBlockAlign     4
xrdp-chansrv [0784982965]:       wBitsPerSample  16
xrdp-chansrv [0784982965]:       cbSize          0
xrdp-chansrv [0784982965]: sound_process_output_format:
xrdp-chansrv [0784982965]:       wFormatTag      1
xrdp-chansrv [0784982965]:       nChannels       2
xrdp-chansrv [0784982965]:       nSamplesPerSec  22050
xrdp-chansrv [0784982965]:       nAvgBytesPerSec 88200
xrdp-chansrv [0784982965]:       nBlockAlign     4
xrdp-chansrv [0784982965]:       wBitsPerSample  16
xrdp-chansrv [0784982965]:       cbSize          0
xrdp-chansrv [0784982965]: sound_process_output_format:
xrdp-chansrv [0784982965]:       wFormatTag      85
xrdp-chansrv [0784982965]:       nChannels       2
xrdp-chansrv [0784982965]:       nSamplesPerSec  44100
xrdp-chansrv [0784982965]:       nAvgBytesPerSec 176400
xrdp-chansrv [0784982965]:       nBlockAlign     4
xrdp-chansrv [0784982965]:       wBitsPerSample  0
xrdp-chansrv [0784982965]:       cbSize          12
0000 01 00 02 00 00 00 b6 00 01 00 71 05             ..........q.
xrdp-chansrv [0784982965]: wFormatTag, mp3
xrdp-chansrv [0784983069]: sound_process_training: round trip time 104
xrdp-chansrv [0784983140]: scard_init:
chansrv:smartcard_pcsc [0784983140]: scard_pcsc_init:
[0785157961]: CLIPFILE   clipboard_c2s_in_files: 670 : ERROR: clipboard_c2s_in_files: failed to add clip dir item

[matt335672]

I'm afraid that's normal behaviour at the moment. The chansrv logging is split between stdout, and the chansrv log, which comes down to the way it's been developed over the years.

There's a PR #1633 which will address most of this which will get merged after v0.9.14 is out.

In this comment you're showing chansrv as having stdout and stderr redirected to /dev/null. That would explain the difference.

I think chansrv just inherits stdout and stderr from sesman. So if you redirect sesman output (however you're starting sesman) to another file that should clean up your docker stdout.

[matt335672]

Hi @endofreal

Do you need any more help with this, or can I close the issue?

Thanks.

[endofreal]

Hi @matt335672 !

If I make a build from branch of your repository, the problem is not represents, but if make a build from current devel branch of xrdp project I have it (chansrv become defunct without any messages).

Could you please update your repo with current xrdp devel branch and apply fix again? Maybe it will useful for next time.

[matt335672]

I've rebased my branch for you.

I'm going to merge this into devel hopefully soon, but there are a few other things to get merged first. When I merge it I'll close this issue.

[endofreal]

Hi @matt335672 !

I've made a build from your repository and it works perfectly! xrdp-chansrv no more fails!
In stdout I've seen next:

[1936866977]: FUSE       xfuse_init_lib: 804 : ERROR: fuse_mount() failed
xrdp-chansrv [1936867006]: xcommon_init: connected to display ok
[1936867007]: FUSE       xfuse_init_lib: 804 : ERROR: fuse_mount() failed
xrdp-chansrv [1936867007]: sound_init:
[1936867007]: FUSE       xfuse_init_lib: 804 : ERROR: fuse_mount() failed
xrdp-chansrv [1936867007]: audin_init:
xrdp-chansrv [1936867026]: sound_process_output_format:
xrdp-chansrv [1936867026]:       wFormatTag      1
xrdp-chansrv [1936867026]:       nChannels       2
xrdp-chansrv [1936867026]:       nSamplesPerSec  44100
xrdp-chansrv [1936867026]:       nAvgBytesPerSec 176400
xrdp-chansrv [1936867026]:       nBlockAlign     4
xrdp-chansrv [1936867026]:       wBitsPerSample  16
xrdp-chansrv [1936867026]:       cbSize          0
xrdp-chansrv [1936867026]: sound_process_output_format:
xrdp-chansrv [1936867026]:       wFormatTag      1
xrdp-chansrv [1936867026]:       nChannels       2
xrdp-chansrv [1936867026]:       nSamplesPerSec  22050
xrdp-chansrv [1936867026]:       nAvgBytesPerSec 88200
xrdp-chansrv [1936867026]:       nBlockAlign     4
xrdp-chansrv [1936867026]:       wBitsPerSample  16
xrdp-chansrv [1936867026]:       cbSize          0
xrdp-chansrv [1936867026]: sound_process_output_format:
xrdp-chansrv [1936867026]:       wFormatTag      85
xrdp-chansrv [1936867026]:       nChannels       2
xrdp-chansrv [1936867026]:       nSamplesPerSec  44100
xrdp-chansrv [1936867026]:       nAvgBytesPerSec 176400
xrdp-chansrv [1936867026]:       nBlockAlign     4
xrdp-chansrv [1936867026]:       wBitsPerSample  0
xrdp-chansrv [1936867026]:       cbSize          12
0000 01 00 02 00 00 00 b6 00 01 00 71 05             ..........q.
xrdp-chansrv [1936867026]: wFormatTag, mp3
xrdp-chansrv [1936867127]: sound_process_training: round trip time 101
xrdp-chansrv [1936867219]: scard_init:
chansrv:smartcard_pcsc [1936867219]: scard_pcsc_init:
[20200909-18:18:38] [ERROR] clipboard_event_selection_request: unknown target text/plain;charset=utf-8
[1936892320]: CLIPFILE   clipboard_c2s_in_files: 670 : ERROR: clipboard_c2s_in_files: failed to add clip dir item
[1936892329]: CLIPFILE   clipboard_c2s_in_files: 670 : ERROR: clipboard_c2s_in_files: failed to add clip dir item
[1936899267]: CLIPFILE   clipboard_c2s_in_files: 670 : ERROR: clipboard_c2s_in_files: failed to add clip dir item
[1936899275]: CLIPFILE   clipboard_c2s_in_files: 670 : ERROR: clipboard_c2s_in_files: failed to add clip dir item
[1936918617]: CLIPBOARD  clipboard_event_selection_notify: 1954 : ERROR: clipboard_event_selection_notify: unknown atom 0xf9
[1936918617]: CLIPBOARD  clipboard_event_selection_notify: 1954 : ERROR: clipboard_event_selection_notify: unknown atom 0xfa
[1936918617]: CLIPBOARD  clipboard_event_selection_notify: 1954 : ERROR: clipboard_event_selection_notify: unknown atom 0xfb
[1936918617]: CLIPBOARD  clipboard_event_selection_notify: 1954 : ERROR: clipboard_event_selection_notify: unknown atom 0x199
[1936918617]: CLIPBOARD  clipboard_event_selection_notify: 1954 : ERROR: clipboard_event_selection_notify: unknown atom 0x1db
[1936918617]: CLIPBOARD  clipboard_event_selection_notify: 1954 : ERROR: clipboard_event_selection_notify: unknown atom 0x1a9
[1936918617]: CLIPBOARD  clipboard_event_selection_notify: 1954 : ERROR: clipboard_event_selection_notify: unknown atom 0x1e9
rdpkeybBell:

I thoughts that fix must be included into this project.

[matt335672]

Hi @endofreal

I don't quite understand your comment.

If you mean we should be merging this fix, we will.

If you're referring to the messages above, I think you'll get those if the FUSE file system isn't active. they're quite harmless and can be ignored.

[endofreal]

@matt335672

I just want to tell you that all works fine and you should merge this fix.

Thank you!

[ChriFo]

@matt335672 I think I have the same problem with the current devel as well as with a build from your branch issue1658-2.

I have two almost identical setups - one is running on a Debian (buster) and one on macOS (10.15.7, my workstation).
XRDP is installed in Docker from an Arch Linux image with an Openbox desktop. The Client is a Guacamole (1.2.0) setup with three container (Webserver + Guacd + DB).

Here are the (maybe) relevant parts of the XRDP configuration files.
sesman.ini

[Chansrv]
FuseMountName=transfer
FileUmask=077

xrdp.ini

[Globals]
allow_channels=true
allow_multimon=false
bitmap_cache=true
bitmap_compression=true
bulk_compression=true
max_bpp=16
new_cursors=true
use_fastpath=none

[Channels]
rdpdr=true
rdpsnd=false
drdynvc=true
cliprdr=true
rail=false
xrdpvr=true
tcutils=false

When transferring a big file (20GB) from the GUACFS mount point (/home/christian.fochler/transfer/GUACFS) into the home folder (/home/christian.fochler) it sometimes failed shortly after some megabytes or when canceling the transfer:

This is stdout of sesman (XRDP build from issue1658-2) when the error appeared:

chansrv::main: using log file [/home/christian.fochler/.local/share/xrdp/xrdp-chansrv.10.log]
[20201007-16:38:46] [CORE ] main: app started pid 268(0x0000010c)
[20201007-16:38:46] [INFO ] main: DISPLAY env var set to :10.0
[20201007-16:38:46] [INFO ] main: using DISPLAY 10
[20201007-16:38:46] [INFO ] channel_thread_loop: thread start
[20201007-16:38:46] [INFO ] Socket 12: AF_UNIX connection received
process_message_channel_setup: chan name 'cliprdr' id 0 flags 00000000
process_message_channel_setup: chan name 'rdpdr' id 1 flags 00000000
process_message_channel_setup: chan name 'rdpsnd' id 2 flags 00000000
process_message_channel_setup: chan name 'drdynvc' id 3 flags 00000000
xrdp-chansrv [0058724944]: child_signal_handler:
xrdp-chansrv [0058724944]: child_signal_handler: child pid -1
xrdp-chansrv [0058724964]: xcommon_init: connected to display ok
xrdp-chansrv [0058724966]: sound_init:
xrdp-chansrv [0058724966]: audin_init:
[0059851953]: CLIPBOARD  clipboard_event_selection_notify: 1954 : ERROR: clipboard_event_selection_notify: unknown atom 0x165
[0059851953]: CLIPBOARD  clipboard_event_selection_notify: 1954 : ERROR: clipboard_event_selection_notify: unknown atom 0x166
[0059851953]: CLIPBOARD  clipboard_event_selection_notify: 1954 : ERROR: clipboard_event_selection_notify: unknown atom 0x167
[0059872387]: CLIPBOARD  clipboard_event_selection_notify: 1954 : ERROR: clipboard_event_selection_notify: unknown atom 0x165
[0059872387]: CLIPBOARD  clipboard_event_selection_notify: 1954 : ERROR: clipboard_event_selection_notify: unknown atom 0x166
[0059872387]: CLIPBOARD  clipboard_event_selection_notify: 1954 : ERROR: clipboard_event_selection_notify: unknown atom 0x167
[0059896923]: DEV_REDIR  devredir_data_in: 354 : ERROR: invalid component type in response; expected 0x4472 got 0xf5b6
process_message: error rv -1 id 5
xrdp-chansrv [0059896925]: segfault_signal_handler: entered.......
xrdp-chansrv [0059897067]: child_signal_handler:
xrdp-chansrv [0059897067]: child_signal_handler: child pid -1

And stdout from sesman from the current devel branch:

chansrv::main: using log file [/home/christian.fochler/.local/share/xrdp/xrdp-chansrv.11.log]
[20201007-17:05:18] [CORE ] main: app started pid 53(0x00000035)
[20201007-17:05:18] [INFO ] main: DISPLAY env var set to :11.0
[20201007-17:05:18] [INFO ] main: using DISPLAY 11
[20201007-17:05:18] [INFO ] channel_thread_loop: thread start
[20201007-17:05:18] [INFO ] Socket 12: AF_UNIX connection received
process_message_channel_setup: chan name 'cliprdr' id 0 flags 00000000
process_message_channel_setup: chan name 'rdpdr' id 1 flags 00000000
process_message_channel_setup: chan name 'rdpsnd' id 2 flags 00000000
process_message_channel_setup: chan name 'drdynvc' id 3 flags 00000000
xrdp-chansrv [0060317371]: child_signal_handler:
xrdp-chansrv [0060317371]: child_signal_handler: child pid -1
xrdp-chansrv [0060317386]: xcommon_init: connected to display ok
xrdp-chansrv [0060317388]: sound_init:
xrdp-chansrv [0060317388]: audin_init:
[0060333842]: CLIPBOARD  clipboard_event_selection_notify: 1955 : ERROR: clipboard_event_selection_notify: unknown atom 0x164
[0060333842]: CLIPBOARD  clipboard_event_selection_notify: 1955 : ERROR: clipboard_event_selection_notify: unknown atom 0x165
[0060333842]: CLIPBOARD  clipboard_event_selection_notify: 1955 : ERROR: clipboard_event_selection_notify: unknown atom 0x166
[0060341398]: DEV_REDIR  devredir_data_in: 354 : ERROR: invalid component type in response; expected 0x4472 got 0x1c55
process_message: error rv -1 id 5
xrdp-chansrv [0060341398]: segfault_signal_handler: entered.......
xrdp-chansrv [0060341442]: child_signal_handler:
xrdp-chansrv [0060341442]: child_signal_handler: child pid -1

This happened with both setups.
I am very thankful for any help!

[matt335672]

Thanks for the useful report.

I'm done for the day here at the mo', but I'll have a look tomorrow.

Is there anything consistent about the amount of the file which is actually copied?

Thanks

[ChriFo]

I debugged my setup (on the mac) as described here:

Thread 2 "xrdp-chansrv" received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0x7fe1969d6640 (LWP 170)]
0x00005653413aced2 in ?? ()
(gdb) where
#0  0x00005653413aced2 in ?? ()
#1  0x00005653413a2558 in ?? ()
#2  0x00007fe197431132 in trans_check_wait_objs () from /usr/lib/xrdp/libcommon.so.0
#3  0x00005653413a2e4f in ?? ()
#4  0x00007fe1970983e9 in start_thread () from /usr/lib/libpthread.so.0
#5  0x00007fe1971b3293 in clone () from /usr/lib/libc.so.6
(gdb) 

Thread 2 "xrdp-chansrv" received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0x7f498a79c640 (LWP 239)]
0x00007f498afdee12 in __memmove_avx_unaligned_erms () from /usr/lib/libc.so.6
(gdb) where
#0  0x00007f498afdee12 in __memmove_avx_unaligned_erms () from /usr/lib/libc.so.6
#1  0x000055db00065ee2 in ?? ()
#2  0x000055db0005b558 in ?? ()
#3  0x00007f498b1f7132 in trans_check_wait_objs () from /usr/lib/xrdp/libcommon.so.0
#4  0x000055db0005be4f in ?? ()
#5  0x00007f498ae5e3e9 in start_thread () from /usr/lib/libpthread.so.0
#6  0x00007f498af79293 in clone () from /usr/lib/libc.so.6
(gdb) 

Both results are from a build from the current devel branch.
During collecting the results I realize that the error happened in the moment I switch between the browser (with open RDP via Guacamole) and the terminal session (SSH connection to the RDP target). When I wait and watch the status bar the copy process is not failing. The actual size of copied file fragment depends to the moment I "interrupt" the copy process.

[matt335672]

That's useful information - thanks.

The error you're getting from 'DEV_REDIR' is the point at which everything is going wrong. At that point in the code, we're expecting a value of which tells us whether the packet is for the core (which we handle) or a printer (which we don't). The value we're getting is neither of those two things. In both of your failures, the value is different.

It gets worse, in that following the code through a bit further, the unexpected message should just be dropped - clearly this isn't happening. So we've either lost sync with the data stream, or the data stream has been scribbled on by something else.

This is something different from the original fault which was reported.

I'm currently trying to trace the calls back so I can figure out where we need some debugging information inserted, but it's a bit slow.

It looks like you've got some debugging info built into your executables. In gdb, are you able to step up to the trans_check_wait_objs() call and see what it's calling down into?

[ChriFo]

After

Thread 2 "xrdp-chansrv" received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0x7fc2df5ed640 (LWP 208)]
0x0000557d7945fed2 in ?? ()
(gdb) where
#0  0x0000557d7945fed2 in ?? ()
#1  0x0000557d79455558 in ?? ()
#2  0x00007fc2e0048132 in trans_check_wait_objs () from /usr/lib/xrdp/libcommon.so.0
#3  0x0000557d79455e4f in ?? ()
#4  0x00007fc2dfcaf3e9 in start_thread () from /usr/lib/libpthread.so.0
#5  0x00007fc2dfdca293 in clone () from /usr/lib/libc.so.6
(gdb) info args
No symbol table info available.

To go up I did

(gdb) up
#1  0x0000557d79455558 in ?? ()
(gdb) up
#2  0x00007fc2e0048132 in trans_check_wait_objs () from /usr/lib/xrdp/libcommon.so.0
(gdb) info args
No symbol table info available.
(gdb) up
#3  0x0000557d79455e4f in ?? ()
(gdb) up
#4  0x00007fc2dfcaf3e9 in start_thread () from /usr/lib/libpthread.so.0
(gdb) up
#5  0x00007fc2dfdca293 in clone () from /usr/lib/libc.so.6
(gdb) up
Initial frame selected; you cannot go up.
(gdb) 

@matt335672 I like to help but I am new to gdb.

[matt335672]

Hi @ChriFo

Sorry - I'm not really being very clear. I'll try to be clearer.

Your stack trace looks like it's missing some information in any case, so I think we need to resolve that first.

Normally the output of the XRDP build and installation process produces executables containing debug information which makes using GDB a lot easier to use. Your executables seem to be missing this.

Is it possible that in the process of constructing your Docker image from the devel version some of the executables have become stripped? This would be done by using make install-strip rather than make install when the Docker image was constructed. The difference between these two commands is explained here [gnu.org].

If this is the case, could I trouble you to rebuild your images with make install rather than make install-strip? This will make them a little larger but won't alter the functionaltiy.

Once this is done, the output of the gdb where command will be much more informative. It will contain more function names, file names and line numbers.

If you're able to provide your Dockerfile or a link to it, I'll be happy to try to reproduce your issue here using a containerised Guacamole.

In any case, the output of the following two commands (run in the Docker container filesystem) will be useful to give us more information:-

xrdp -v
file -L /usr/lib/xrdp/libcommon.so.0

Thanks.

[ChriFo]

@matt335672 That was clear enough :-)

I learned that Arch Linux has default options enabled including strip. I adjusted the file PKGBUILD accordingly.

The output of xrdp -v is now:

xrdp 0.9.14
  A Remote Desktop Protocol Server.
  Copyright (C) 2004-2018 Jay Sorg, Neutrino Labs, and all contributors.
  See https://github.com/neutrinolabs/xrdp for more information.

  Configure options:
      --prefix=/usr
      --sysconfdir=/etc
      --localstatedir=/var
      --sbindir=/usr/bin
      --without-systemdsystemunitdir
      --enable-tjpeg
      --enable-fuse
      --enable-pixman
      --enable-vsock
      --disable-rfxcodec
      --disable-pam
      CFLAGS=-march=x86-64 -mtune=generic -O2 -pipe -fno-plt -g -fvar-tracking-assignments -fdebug-prefix-map=/tmp/xrdp/src=/usr/src/debug
      LDFLAGS=-Wl,-O1,--sort-common,--as-needed,-z,relro,-z,now
      CPPFLAGS=-D_FORTIFY_SOURCE=2

  Compiled with OpenSSL 1.1.1h  22 Sep 2020

file -L /usr/lib/xrdp/libcommon.so.0 shows:

/usr/lib/xrdp/libcommon.so.0: ELF 64-bit LSB shared object, x86-64, version 1 (SYSV), dynamically linked, BuildID[sha1]=2e4adc8d95c82f7b1ec755a5c8da943edc3a3d7b, with debug_info, not stripped

And the dbg shows this in case of an exception:

Thread 2 "xrdp-chansrv" received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0x7fbf7b763640 (LWP 173)]
0x000055d46b745ed2 in devredir_data_in (s=0x7fbf74015640, chan_id=1, chan_flags=13550, length=1600, 
    total_length=1600) at devredir.c:334
334 devredir.c: No such file or directory.
(gdb) where
#0  0x000055d46b745ed2 in devredir_data_in (s=0x7fbf74015640, chan_id=1, chan_flags=13550, length=1600, 
    total_length=1600) at devredir.c:334
#1  0x000055d46b73b558 in process_message_channel_data (s=0x7fbf74015640) at chansrv.c:465
#2  process_message () at chansrv.c:862
#3  my_trans_data_in (trans=<optimized out>) at chansrv.c:921
#4  my_trans_data_in (trans=<optimized out>) at chansrv.c:896
#5  0x00007fbf7c1be132 in trans_check_wait_objs (self=0x7fbf74015390) at trans.c:426
#6  0x000055d46b73be4f in channel_thread_loop (in_val=<optimized out>) at chansrv.c:1439
#7  0x00007fbf7be253e9 in start_thread () from /usr/lib/libpthread.so.0
#8  0x00007fbf7bf40293 in clone () from /usr/lib/libc.so.6
(gdb) 

Somehting is not there devredir.c: No such file or directory. :thinking:

If needed I will try to strip down the Dockerfile for a _minimal working example_.

[matt335672]

Thanks for that.

I can't work out exactly where things are going wrong from devredir.c:334 - that line looks pretty innocuous in the current devel branch:-

https://github.com/neutrinolabs/xrdp/blob/62befaa803b2c0ed8e7fc9498623c7b7db943b74/sesman/chansrv/devredir.c#L334

Is the Arch build applying any patches to devel?

The code in this area is dealing with defragmenting messages passed in multiple packets. This code is definitely a bit flaky in that if the fragmentation flags are even a bit wrong, bad things will happen.

I've run out of time today, but I'll give this a priority tomorrow. I can add some extra logging in this area which may illustrate what's going on. If I supply you with a patch, is it easy enough to get into your build environment?

[ChriFo]

Is the Arch build applying any patches to devel?

Yes. https://aur.archlinux.org/cgit/aur.git/tree/arch-config.diff?h=xrdp-git

If I supply you with a patch, is it easy enough to get into your build environment?

Of course yes! Thank you very much again!

[matt335672]

Hi @ChriFo

I've created a patch from a branch in my xrdp repo which adds some additional checking to the defragmentation code in devredir.c. It removes a possible source of coredumps.

https://github.com/neutrinolabs/xrdp/commit/06931856081cb27dab4bf2c5135f89a7aa07d37b.patch

You should be able to pull that down with wget/curl or whatever and add it in to the PKGBUILD.

I'm not that familiar with Arch I'm afraid, Can you also remove the -O2 flag from the C compiler arguments? That might help with the odd line numbers on the stack traces if we continue to get them.

Let me know how you get on. I suspect we'll need to make some further changes to resolve this.

Thanks again.

[ChriFo]

I was able to compile without -O2 (heavy editing in configure.ac :unamused:):

xrdp 0.9.14
  A Remote Desktop Protocol Server.
  Copyright (C) 2004-2018 Jay Sorg, Neutrino Labs, and all contributors.
  See https://github.com/neutrinolabs/xrdp for more information.

  Configure options:
      --prefix=/usr
      --sysconfdir=/etc
      --localstatedir=/var
      --sbindir=/usr/bin
      --without-systemdsystemunitdir
      --enable-tjpeg
      --enable-fuse
      --enable-pixman
      --enable-vsock
      --disable-rfxcodec
      --disable-pam
      CFLAGS=-march=x86-64 -mtune=generic -O0 -pipe -fno-plt -g -fvar-tracking-assignments -fdebug-prefix-map=/tmp/xrdp/src=/usr/src/debug
      LDFLAGS=-Wl,-O0,--sort-common,--as-needed,-z,relro,-z,now
      CPPFLAGS=-D_FORTIFY_SOURCE=2

  Compiled with OpenSSL 1.1.1h  22 Sep 2020

And I applied your patch:

Thread 2 "xrdp-chansrv" received signal SIGABRT, Aborted.
[Switching to Thread 0x7f445d573640 (LWP 59)]
0x00007f445dc8d615 in raise () from /usr/lib/libc.so.6
(gdb) where
#0  0x00007f445dc8d615 in raise () from /usr/lib/libc.so.6
#1  0x00007f445dc76862 in abort () from /usr/lib/libc.so.6
#2  0x00007f445dccf5e8 in __libc_message () from /usr/lib/libc.so.6
#3  0x00007f445dcd727a in malloc_printerr () from /usr/lib/libc.so.6
#4  0x00007f445dcd897c in _int_free () from /usr/lib/libc.so.6
#5  0x00007f445dfc9ac7 in g_free (ptr=0x7f4458041970) at os_calls.c:202
#6  0x0000556a4a65015c in devredir_data_in (s=0x7f4458015640, chan_id=1, chan_flags=15302, length=1600, total_length=1896232115) at devredir.c:457
#7  0x0000556a4a63fb2f in process_message_channel_data (s=0x7f4458015640) at chansrv.c:465
#8  0x0000556a4a64098e in process_message () at chansrv.c:862
#9  0x0000556a4a640b0c in my_trans_data_in (trans=0x7f4458015390) at chansrv.c:921
#10 0x00007f445dfd0669 in trans_check_wait_objs (self=0x7f4458015390) at trans.c:426
#11 0x0000556a4a641b92 in channel_thread_loop (in_val=0x0) at chansrv.c:1439
#12 0x00007f445dc353e9 in start_thread () from /usr/lib/libpthread.so.0
#13 0x00007f445dd50293 in clone () from /usr/lib/libc.so.6
(gdb) 

(I wanted to report "Present But Cannot Be Compiled" findings to xrdp-devel, but I was not able to join.)

[matt335672]

That's excellent work - thanks.

The stack trace is showing a crash in the free() C library call. At a first glance the pointer which is being passed in looks valid, and so this is likely to be a corruption of the heap data structures which has been caused by processing the last message.

It's going to be a pig to find however.

I think the best way forward is for me to try to reproduce it here. I'll set up a containerised Guacamole and try to reproduce what you've seen above. I don't think using your containerised XRDP will be necessary at this stage. The rest of your instructions seem pretty clear (20GB file on GUACFS, copy to home directory). I'll let you know how I got on. Feel free to nag me in a couple of days if you haven't heard anything.

[matt335672]

Quick update so you know I haven't forgotten this - I've set up a containerised Guacamole using Ubuntu 18.04 as a target (GNOME WM), and I'm not managing to reproduce this at the moment.

I'll persist for a bit before we consider other options. I don't doubt this is a problem in chansrv, but it may be down to the way that Openbox is running the copy.

[matt335672]

@ChriFo

I'm still having problems reproducing this.

I've set up an Ubuntu 20.04 VM with openbox and the PCManFM file manager (which it looks like you're using). I'm logging in from a containerised Guacamole and copying a 5.4GB file from guacd to the home directory on the Ubuntu server. I'm using drag-and-drop to start the copy. This file copy works fine with no segfaults in chansrv. I'm swapping windows quite a bit during the copy, and all seems well.

Do any differences jump out at you? What file manager are you using, and which version?

Thanks

[ChriFo]

@matt335672 With your message before the last I rebuild the whole image from then last develop branch. With this version I am also unable to reproduce the failure. Copying 20GB from guacd to the home folder was no problem - including browser window switch, resizing and dialog dragging...

I am sorry to waste your time and for not finding a real bug but only some kind of _dependency clash_. Thank you very much for a great piece of software and for your time!!

To answer your question: I am using Thunar.

[matt335672]

Thanks for the update, and the chat. It's been interesting even though we didn't find anything!

I'll retry with Thunar and see if I can get any more insight. If I can't I'll mark this issue to be closed when #1703 is merged, as this contains the fix for the original issue.

[matt335672]

I've retried with Thunar, and I'm unable to find any problems with a 5.1 GiB file copy.