You On Fri, Jul 24, 2020 at 4:14 PM Amarjeet Singh <[email protected]> wrote:
> Hi Team, > > > More analysis on this :- > > There are threads which are in deadlock: > > THREAD *25377 *is waiting for the mutex lock whereas THREAD *25376 *is > stuck in a *write *system call Because of which there are connections > which are in CLOSE_WAIT. > What about this leads you to believe there is deadlock? There is nothing inherently abnormal about a thread being in the middle of a write() when the process is suspended and inspected by gdb. Are you certain that this write() is blocked? If so, are you certain that the write() is blocked by a resource that will not be released until that write() succeeds (deadlock)? Your backtrace shows two instructions being written simultaneously (one "sync" and another "error"), with the socket lock ensuring those instructions do not overlap. This is also normal behavior and not deadlock; it is simply two threads sharing access to the same guac_socket. If you are seeing a great many sockets stuck in CLOSE_WAIT, that does sound like there may be a case where file descriptors are not being properly released, but the information here so far just looks like snapshots of a normal, properly-functioning guac process. If you can trace down which file descriptors specifically are being held, and by which process, then that coupled with logs might reveal what conditions are necessary for this to occur. So far, I think you're just snapshotting the processes that are functioning normally. - Mike
