Menu

#167 dtsession: segfault when an application calls SmcCloseConnection()

fixed
nobody
None
2026-05-31
2024-04-16
Ayron
No

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.

1 Attachments

Discussion

  • Trung Le

    Trung Le - 2026-05-18

    Root cause: When a client calls SmcCloseConnection() with reason messages, dtsession's flow is:

    1. _XtProcessIceMsgProc (SmWatch.c:124) calls IceProcessMessages (dispatch_level → 1)
    2. libSM dispatches the close-connection message → CloseConnectionProc
    3. CloseConnectionProc calls PostReasonsDialog(..., True) which spins in a nested XtAppNextEvent loop (SmUI.c:2483–2491)
    4. While the dialog is up, the client process exits, closing its socket. Xt sees readable data on the ICE fd and recursively invokes _XtProcessIceMsgProcIceProcessMessages (dispatch_level → 2)
    5. The recursive call sees EOF → returns IceProcessMessagesIOError → SmWatch.c:141 calls CloseDownClient, which calls SmsCleanUp and IceCloseConnection (free_asap=True, but not freed because dispatch_level > 0).
      Sets pClientRec->smConn = NULL, iceConn = NULL.
    6. User clicks OK; PostReasonsDialog returns.
    7. CloseConnectionProc calls CloseDownClient again — but now smConn/iceConn are NULL → SmsCleanUp(NULL) / IceSetShutdownNegotiation(NULL,…) → crash.

    Fix: Pass False for waitForResponse so the dialog is displayed but CloseConnectionProc returns immediately. CloseDownClient then runs synchronously (still inside the outer IceProcessMessages, which libICE handles
    safely via its dispatch_level/free_asap mechanism), XtRemoveInput detaches the ICE fd, and no recursive entry into _XtProcessIceMsgProc is possible. The dialog stays up; SimpleOK cleanly unmanages it when the user
    clicks OK. The waitForResponse=True behavior was only really needed for the shutdown path, not for a routine client close.

     
  • Jon Trulson

    Jon Trulson - 2026-05-31
    • status: open --> fixed
     
  • Jon Trulson

    Jon Trulson - 2026-05-31

    Patch applied, nice find!

     

Log in to post a comment.