*Stack Trace:*

#0  0x00007fbfa80b78eb in __GI_raise (sig=sig@entry=6)
    at ../sysdeps/unix/sysv/linux/raise.c:50
#1  0x00007fbfa80a2535 in __GI_abort () at abort.c:79
#2  0x00007fbfa80f9648 in __libc_message
    (action=action@entry=do_abort, fmt=fmt@entry=0x7fbfa82032a0 "%s\n")
    at ../sysdeps/posix/libc_fatal.c:181
#3  0x00007fbfa80ffd6a in malloc_printerr
    (str=str@entry=0x7fbfa8204f50 "free(): double free detected in tcache 2")
    at malloc.c:5359
#4  0x00007fbfa810186d in _int_free
    (av=0x7fbf9c000020, p=0x7fbf9c0bf800, have_lock=<optimized out>)
    at malloc.c:4208
#5  0x00007fbfa5710c00 in Stream_Free ()
    at /lib/x86_64-linux-gnu/libwinpr2.so.2
#6  0x00007fbfa58f8e5d in  () at /lib/x86_64-linux-gnu/libfreerdp2.so.2
#7  0x00007fbfa58f947a in  () at /lib/x86_64-linux-gnu/libfreerdp2.so.2
#8  0x00007fbfa58fa077 in freerdp_channels_check_fds ()
    at /lib/x86_64-linux-gnu/libfreerdp2.so.2
#9  0x00007fbfa58f7965 in freerdp_check_event_handles ()
    at /lib/x86_64-linux-gnu/libfreerdp2.so.2
#10 0x00007fbfa59ee62d in guac_rdp_handle_connection (client=0x7fbf9800b350)
    at rdp.c:558
#11 0x00007fbfa59ee62d in guac_rdp_client_thread (data=0x7fbf9800b350)
--Type <RET> for more, q to quit, c to continue without paging--
#12 0x00007fbfa8920fa3 in start_thread (arg=<optimized out>)
    at pthread_create.c:486
#13 0x00007fbfa817906f in clone ()
    at ../sysdeps/unix/sysv/linux/x86_64/clone.S:95


---------
Syslog:

Jan 24 19:32:39 n104-224-077 guacd[1306089]: Connected to RDPDR 1.13 as
client 0x0003

Jan 24 19:32:39 n104-224-077 coredump_handler: coredump argv[3] is
!usr!local!sbin!guacd

Jan 24 19:32:39 n104-224-077 guacd[1334641]: Connection
"$2f63f3d6-54f0-46dc-ac87-4a1c0139996d" removed.

Jan 24 19:33:49 n104-224-077 guacd[1334641]: Creating new client for
protocol "rdp"

Jan 24 19:33:49 n104-224-077 guacd[1334641]: Connection ID is
"$5ef52daa-faa0-495e-a100-9920acc4b09a"

Jan 24 19:33:49 n104-224-077 guacd[1399195]: Security mode: Negotiate (ANY)

Jan 24 19:33:49 n104-224-077 guacd[1399195]: Resize method: none

Jan 24 19:33:49 n104-224-077 guacd[1399195]: No clipboard line-ending
normalization specified. Defaulting to preserving the format of all line
endings.

Jan 24 19:33:49 n104-224-077 guacd[1399195]: User
"@6f05a09b-54c4-4599-bf4e-336e22cce9ee" joined connection
"$5ef52daa-faa0-495e-a100-9920acc4b09a" (1 users now present)

Jan 24 19:33:49 n104-224-077 guacd[1399195]: Loading keymap "base"

Jan 24 19:33:49 n104-224-077 guacd[1399195]: Loading keymap "en-us-qwerty"

Jan 24 19:33:49 n104-224-077 guacd[1399195]: Connected to RDPDR 1.13 as
client 0x0003

Jan 24 19:33:49 n104-224-077 coredump_handler: coredump argv[3] is
!usr!local!sbin!guacd

Jan 24 19:33:49 n104-224-077 guacd[1334641]: Connection
"$5ef52daa-faa0-495e-a100-9920acc4b09a" removed.


---------

Core Dump: attached.

On Mon, Jan 23, 2023 at 11:15 AM Nick Couchman <[email protected]> wrote:

> On Mon, Jan 23, 2023 at 10:49 AM Dylan Francis
> <[email protected]> wrote:
> >
> > Guacamole is working, mostly.
> > Installed Guacamole on a Debian 10 machine using the Linode guide. We
> replaced all mentions of 1.3.0 with 1.4.0 as the guide is slightly out of
> date.
> > The only thing that was missing from the guide is the guacd.conf file,
> which we added manually during setup.
> > [server]
> > bind_host = 0.0.0.0
> > bind_port = 4822
> >
> > The guacd service is able to write to the relevant directory within the
> Debian filesystem, as the user account folder is properly created when the
> connection first occurs.
> >
> > When we try to connect with the file share enabled, the connection is
> successful, but as soon as the cursor moves the connection drops. The same
> behavior occurs if audio is enabled (but that is something we can get away
> with leaving turned off)
> > Drive Name: share
> > Drive Path: /home/guacamole/share/${GUAC_USERNAME}
> > Automatically Create Drive: Enabled
> >
> > This behavior is occurring on three independent Guacamole VMs, in two
> different areas of our environment. The guacd service looks to be crashing,
> and we have the coredump files.
>
> We'll need the stack trace from the core dumps in order to further
> debug this issue. I use Guacamole 1.4.0 on a daily basis with file
> transfer enabled, and I do not see any crashes as a result, so I
> cannot reproduce the issue.
>
> Please provide stack trace (backtrace in gdb) output.
>
> -Nick
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [email protected]
> For additional commands, e-mail: [email protected]
>
>

Attachment: Core Dump.tar.gz
Description: GNU Zip compressed data

---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]

Reply via email to