Hi Mike! what's happening is kind of crazy -- and I'd really appreciate more of your advice getting to the bottom of this. Here's what I did:
$ gdb /usr/sbin/guacd (gdb) set follow-fork-mode child (gdb) attach 1 (gdb) cont Continuing. [New LWP 29] [New process 30] [New LWP 33] [New LWP 34] [New LWP 35] [New LWP 36] Thread 2.4 "guacd" received signal SIGSEGV, Segmentation fault. [Switching to LWP 35] guac_vnc_clipboard_end_handler (user=<optimized out>, stream=<optimized out>) at clipboard.c:109 109 char* output = output_data; (gdb) So you were absolutely right -- it did SIGSEGV and I guess we need to the bottom of this. However, the crazy part is this: the sub-process that SIGSEGVed is now stopped by gdb, however (since I accidentally clicked on reconnect in the GUI) the new sub-process that got forked is complete fine. In fact, for as long as I keep the SIGSEGVed one stopped I can start new sessions, interact with my VNC and everything looks just peachy. I can even fully disconnect/reconnect (making sure that new sub-processes get forked) and all that is totally fine. Any ideas on what could cause this weird behaviour (and also what could be a potential cause for the SIGSEGV above)? Thanks, Roman. On Fri, Nov 16, 2018 at 9:30 PM Roman Shaposhnik <ro...@shaposhnik.org> wrote: > > On Fri, Nov 16, 2018 at 12:31 AM Mike Jumper <mjum...@apache.org> wrote: > > > > On Wed, Nov 14, 2018 at 10:52 PM Roman Shaposhnik <r...@apache.org> wrote: > > > > > Hi! > > > > > > first of all -- just wanted to say that Guacamole is one > > > impressive project -- very well done. > > > > > > Thanks! > > > > ... > > > guacd[9]: INFO: User "@6c100210-b28a-46ae-9db7-00b30782b5c2" joined > > > connection "$b8a08e42-bb09-4d10-8631-9143ea018a5c" (1 users now > > > present) > > > guacd[9]: TRACE: Server completed frame 119195788ms. > > > guacd[1]: INFO: Connection "$b8a08e42-bb09-4d10-8631-9143ea018a5c" > > > removed. > > > > > > > If the connection terminated normally, there would be additional log > > messages before that "Connection removed" message mentioning that the user > > is disconnected, the VNC connection is closed, etc. Those messages would be > > logged by the process handling the VNC connection (in this case PID 9). The > > fact that those messages do not appear suggests that the process handling > > the VNC connection may have crashed. > > That's very helpful! Thanks! > > > Are you able to run a debugger under Alpine? > > Yes. So let me attach gdb to guacd and see if any of the forked off > processes core dump > or exit abnormally. Will let you know tomorrow. > > Thanks, > Roman.
