Debug builds can cause xrdp-chansrv to hang on exit on a futex.

[matt335672]

Similar to #1729.

I don't think this is a huge problem at the moment as it just affects debug builds. It's something however to be aware of as this will cause the session not to exit properly, so can cause symptoms like those seen in #2021

A complete solution will involve a re-working of the signal handler code.

When xrdp-chansrv receives a signal, it logs it using code like the following, which only triggers on a debug build:-

    LOG_DEVEL(LOG_LEVEL_INFO, "term_signal_handler: got signal %d", sig);

The problem is that the calls used by the logging sub-system are not thread safe. I just now ended up with xrdp-chansrv waiting on a futex:-

$ strace -p 7727
strace: Process 7727 attached
futex(0x7f22e7b9fb80, FUTEX_WAIT_PRIVATE, 2, NULL

The stack trace from gdb was:-

$ gdb /usr/local/sbin/xrdp-chansrv 7727
. . .
(gdb) where
#0  __lll_lock_wait_private (futex=0x7f22e7b9fb80 <main_arena>)
    at ./lowlevellock.c:35
#1  0x00007f22e7a52fd7 in __libc_calloc (n=n@entry=1, 
    elem_size=elem_size@entry=8192) at malloc.c:3399
#2  0x00007f22e7a42958 in __GI___open_memstream (
    bufloc=bufloc@entry=0x7ffce69646a0, sizeloc=sizeloc@entry=0x7ffce69646a8)
    at memstream.c:83
#3  0x00007f22e7acee35 in __vsyslog_internal (pri=30, fmt=0x7f22e7d6b129 "%s", 
    ap=0x7ffce6964790, mode_flags=0) at ../misc/syslog.c:181
#4  0x00007f22e7acf3ea in __syslog (pri=<optimised out>, 
    fmt=fmt@entry=0x7f22e7d6b129 "%s") at ../misc/syslog.c:117
#5  0x00007f22e7d6037e in internal_log_message (lvl=lvl@entry=LOG_LEVEL_INFO, 
    override_destination_level=override_destination_level@entry=0, 
    override_log_level=LOG_LEVEL_NEVER, 
    msg=msg@entry=0x7ffce6966950 "[term_signal_handler(chansrv.c:1510)] term_signal_handler: got signal %d", ap=ap@entry=0x7ffce6966938) at log.c:972
#6  0x00007f22e7d5ffac in log_message_with_location (
    function_name=0x55e6038c4bd0 <__func__.4717> "term_signal_handler", 
    file_name=0x55e6038c402d "chansrv.c", line_number=1510, 
    level=LOG_LEVEL_INFO, 
    msg=0x55e6038c45e8 "term_signal_handler: got signal %d") at log.c:880
#7  0x000055e60388f4b1 in term_signal_handler (sig=15) at chansrv.c:1510
#8  <signal handler called>
#9  0x00007f22e7acc12b in __GI___select (nfds=nfds@entry=10, 
    readfds=readfds@entry=0x7ffce6969070, 
    writefds=writefds@entry=0x7ffce69690f0, exceptfds=exceptfds@entry=0x0, 
    timeout=timeout@entry=0x0) at ../sysdeps/unix/sysv/linux/select.c:41
#10 0x00007f22e7d639a0 in g_obj_wait (read_objs=0x7ffce69691c0, rcount=2, 
    write_objs=0x0, wcount=0, mstimeout=0) at os_calls.c:2076
#11 0x000055e60388fed1 in main (argc=1, argv=0x7ffce69695e8) at chansrv.c:1783