Whenever an application calls SmcCloseConnection() a message dialogue pops up showing the message passed to SmcCloseConnection(). When the user clicks Ok, dtsession segfaults. I backtraced the coredump and the last line in dtsession is SmWatch.c:124.
I tested on Debian 12 and gentoo. Both behave the same. The attached test program can reproduce the bug.
Root cause: When a client calls SmcCloseConnection() with reason messages, dtsession's flow is:
_XtProcessIceMsgProc(SmWatch.c:124) callsIceProcessMessages(dispatch_level → 1)CloseConnectionProcCloseConnectionProccallsPostReasonsDialog(..., True)which spins in a nestedXtAppNextEventloop (SmUI.c:2483–2491)_XtProcessIceMsgProc→IceProcessMessages(dispatch_level → 2)IceProcessMessagesIOError→ SmWatch.c:141 calls CloseDownClient, which callsSmsCleanUpandIceCloseConnection(free_asap=True, but not freed because dispatch_level > 0).Sets pClientRec->smConn = NULL, iceConn = NULL.
PostReasonsDialogreturns.CloseConnectionProccallsCloseDownClientagain — but nowsmConn/iceConnareNULL → SmsCleanUp(NULL) / IceSetShutdownNegotiation(NULL,…)→ crash.Fix: Pass
FalseforwaitForResponseso the dialog is displayed butCloseConnectionProcreturns immediately.CloseDownClientthen runs synchronously (still inside the outerIceProcessMessages, which libICE handlessafely via its
dispatch_level/free_asap mechanism),XtRemoveInputdetaches the ICE fd, and no recursive entry into_XtProcessIceMsgProcis possible. The dialog stays up;SimpleOKcleanly unmanages it when the userclicks OK. The
waitForResponse=Truebehavior was only really needed for the shutdown path, not for a routine client close.Patch applied, nice find!