[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[screen-devel] [bug #25089] screen produces zombies

From: Axel Beckert
Subject: [screen-devel] [bug #25089] screen produces zombies
Date: Mon, 14 Oct 2019 12:48:36 -0400 (EDT)
User-agent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/76.0.3809.100 Safari/537.36

Follow-up Comment #5, bug #25089 (project screen):

Hi Amadeusz,

[comment #4 comment #4:]
> from quick look I would say that WNOHANG in waitpid() looks suspicious:
> Can you try removing it and see if it still happens?

Bingo! This indeed seems to have solved the issue.

At least I can no more reproduce it as soon as I close all my screen session,
install the patched version (via patched Debian package) and try to reproduce
it again.

For reproducing, I start a screen session with a lot of windows (87× the line
"screen" in my .screenrc for testing purposes, around 30 probably already
suffice), then wait until all shells have properly started up, then I do C-a
C-p until I'm at approximately window 52. If I then press C-d inside a shell
to close one or more of them, with the unpatched version I get as many zombie
process as I closed windows. They vanish all at once when I have close the
last shell inside the screen session together with the session. And the
patched version works as expected, no zombie processes.

After testing with the patched version, I closed my screen session, installed
the unpatched screen version again, and I was able to reproduce the issue
immediately again.

JFTR: this is the patch I applied:

--- a/screen.c
+++ b/screen.c
@@ -1492,7 +1492,7 @@
   if (!wstat_valid && p->w_pid > 0) {
       /* EOF on file descriptor. The process is probably also dead.
        * try a waitpid */
-    if (waitpid(p->w_pid, &wstat, WNOHANG | WUNTRACED) == p->w_pid) {
+    if (waitpid(p->w_pid, &wstat, WUNTRACED) == p->w_pid) {
       p->w_pid = 0;
       wstat_valid = 1;

> You can also try building screen 4.7.0, it should do better system detection
now, so maybe it gets fixed by that.

Didn't change with the screen package from Debian Unstable/Testing (4.7.0-1)
built and installed on Debian 10 Buster.

So I applied the above patch to the 4.7.0-1 Debian package, too, and the issue
was gone, too.

We're now running the patched 4.6.2-3 in production. So far my coworker
couldn't reproduce the issue instantly, but then again, he never tried to
reproduce it on purpose before. (Just I did.)


Reply to this item at:


  Message sent via Savannah

reply via email to

[Prev in Thread] Current Thread [Next in Thread]