#135 SIGSTOP Not handled


If you are running one of the xscreensaver opengl hacks
as your screensaver, and you hit a key to unlock the
screen a just the right moment (explained below) the X server
wedges because it can't get the DRI lock.

The "right moment" is when the screensaver hack has the DRI
lock. When you hit a key, the xscreensaver parent process
sends a SIGSTOP to the screensaver drawing program.

The screensaver drawing program holds the DRI lock, the Xserver
wants to service events for the xscreensaver parent process but
cannot and will block on the DRI lock forever.

I think the answer is not that xscreensaver is broken, I think the
answer is that the DRI locking mechanisms need to be seriously

I think a revisit of these issues will also fix things like having the
X server take the lock even when you wiggle the mouse or when
it's select timeout is hit. Of course it is simple to do the lock
grabbing in the block/wait handling of the X server but this is
far from optimal and also leads to all the problems described in
this bug report.


  • Daryll Strauss

    Daryll Strauss - 2000-06-15
    • assigned_to: nobody --> faith
    • summary: The "debugging DRI app" bug in a different form. --> SIGSTOP Not handled
  • Daryll Strauss

    Daryll Strauss - 2000-06-15

    The locking has been moved down in the tdfx driver, so the xlock case should work at this point assuming the X server doesn't try to do any drawing while the client holds the lock.
    The SIGSTOP problem is a large and difficult one to solve. It's on our list.

  • Rik Faith

    Rik Faith - 2000-08-12
    • priority: 5 --> 9
    • labels: 100211 --> Core Kernel
  • Rik Faith

    Rik Faith - 2000-09-13
    • status: open --> closed-fixed
  • Rik Faith

    Rik Faith - 2000-09-13

    Linus accepted patches into 2.4.0-test7/8 kernels.


Get latest updates about Open Source Projects, Conferences and News.

Sign up for the SourceForge newsletter:

No, thanks