[SOLVED] [BUG] "screen" will not exit unless ^Z

guanx · 10-02-2013, 10:23 AM

Update: Downgraded NVIDIA driver from 319.60 to 319.49 and the problem disappeared.

Hello,

I am running slackware-current (not slackware64-current, not slackwarearm-current, etc.) mirrored from ftp.slackware.com today.

When I start "screen" in an X terminal emulator, e.g. konsole or xterm, then press ^d or type "exit" to end the screen session, or detach from the session with "^a d", screen prints "[screen is terminating]" but I cannot go back to the shell prompt unless pressing ^Z (^C does not work).

There is no such problem in text tty. Only in X terminal emulators.

A recording is attached

Code:

chmod +x bbsplay.txt
./bbsplay.txt screen.log

Any idea? Thanks!

willysr · 10-02-2013, 10:59 AM

i also have a -current machine and it's working fine here
tried ^d and ^a d and both are working

guanx · 10-07-2013, 06:27 AM

[removed]

guanx · 10-07-2013, 11:27 AM

Strace shows that when this problem occurs, screen receives no SIGHUP which it ought to receive. The following patch fixes it but the origin of the bug is unknown to me

Code:

diff -ru screen-4.0.3.orig/screen.c screen-4.0.3/screen.c
--- screen-4.0.3.orig/screen.c  2003-09-08 16:26:41.000000000 +0200
+++ screen-4.0.3/screen.c       2013-10-07 17:15:07.068676486 +0200
@@ -360,14 +360,11 @@
 #if (defined(AUX) || defined(_AUX_SOURCE)) && defined(POSIX)
   setcompat(COMPAT_POSIX|COMPAT_BSDPROT); /* turn on seteuid support */
 #endif
-#if defined(sun) && defined(SVR4)
   {
-    /* Solaris' login blocks SIGHUP! This is _very bad_ */
     sigset_t sset;
     sigemptyset(&sset);
     sigprocmask(SIG_SETMASK, &sset, 0);
   }
-#endif
 
   /*
    *  First, close all unused descriptors

I am terrified by the coding style of screen. I see obvious use-after-free sometimes. The K&R manner gives me an impression that debugging this program is beyond my ability. So ... I don't know how I fixed it, nor will I know in the future.

GazL · 10-07-2013, 11:55 AM

"screen" does have somewhat of a reputation for dodgy code. Have you considered using tmux instead?

guanx · 10-07-2013, 12:03 PM

Quote:

Originally Posted by GazL

"screen" does have somewhat of a reputation for dodgy code. Have you considered using tmux instead?

Not yet, because screen is more widely installed and I see no strong reason to learn a new thing when the old suffices.

volkerdi · 10-07-2013, 08:39 PM

This patch doesn't look correct to me, and this part of the code is unchanged in git. Unless the problem with the code (and the fix) can be adequately explained I'm not going to apply this patch.

Besides that, screen is exiting correctly here on my -current machines in all of the terminal emulators that I tested. Not sure what could be different on your machine.

Thom1b · 10-08-2013, 12:49 AM

Quote:

Originally Posted by guanx

Not yet, because screen is more widely installed and I see no strong reason to learn a new thing when the old suffices.

A good reason is the old is very buggy and doesn't seem maintain. I switched from screen to tmux (maybe two years ago) because of bugs, and I'm very happy with tmux.

guanx · 10-08-2013, 05:20 AM

Quote:

Originally Posted by volkerdi

This patch doesn't look correct to me, and this part of the code is unchanged in git. Unless the problem with the code (and the fix) can be adequately explained I'm not going to apply this patch.

Besides that, screen is exiting correctly here on my -current machines in all of the terminal emulators that I tested. Not sure what could be different on your machine.

I find some bug reports which are probably related to this error:
http://lists.kde.org/?l=kde-core-dev...6773523973&w=4
http://lists.opensuse.org/opensuse-b.../msg05412.html
It looks very much like KDE should be fixed also, because sometimes I get SIGINT blocked upon KDE start, instead of SIGHUP. This is fatal because I use SIGINT much more often (Ctrl-C doesn't work). I confirmed by logging on and off to/from KDE in runlevel 4, and running this simple program:

Code:

$ cat siggetmask.c 
#include <signal.h>

int main()
{
    return siggetmask();
}
$ make siggetmask
cc     siggetmask.c   -o siggetmask
siggetmask.c: In function ‘main’:
siggetmask.c:5:5: warning: ‘siggetmask’ is deprecated (declared at /usr/include/signal.h:203) [-Wdeprecated-declarations]
     return siggetmask();
     ^
$ ./siggetmask; echo $?
1 # sometimes it's 2, but in most cases 1
$

Anyway, because screen must use SIGHUP, it is good practice to ensure it unblocked. This patch above doesn't harm. Does it? I'm novice on signals. Please do point out if I'm wrong. Thanks!

guanx · 10-08-2013, 05:29 AM

Quote:

Originally Posted by Thom1b

A good reason is the old is very buggy and doesn't seem maintain. I switched from screen to tmux (maybe two years ago) because of bugs, and I'm very happy with tmux.

I'd be very happy to use tmux but most of the computers I use don't have it pre-installed. I can only find screen. And I don't have admin privilege on 1/3 of them. It's overkill to install tmux in my $HOME every time I touch a new computer.

Another reason to stay with screen is that when my colleagues ask me how to do something I can simply sent them the screen command, without asking them to install tmux first. Installing something seems more intrusive than running a well known command.

Thom1b · 10-08-2013, 05:36 AM

Quote:

Originally Posted by guanx

I'd be very happy to use tmux but most of the computers I use don't have it pre-installed. I can only find screen. And I don't have admin privilege on 1/3 of them. It's overkill to install tmux in my $HOME every time I touch a new computer.

You're right, this is a good reason to stay with screen.

Quote:

Originally Posted by guanx

Another reason to stay with screen is that when my colleagues ask me how to do something I can simply sent them the screen command, without asking them to install tmux first. Installing something seems more intrusive than running a well known command.

Now tmux is available in many distribution, maybe it's a good idea to suggest Pat to include tmux in slackware.

guanx · 10-08-2013, 07:07 AM

Downgraded NVIDIA driver from 319.60 to 319.49 and the problem disappeared. If the error comes again I will update this thread.

phenixia2003 · 10-08-2013, 12:01 PM

Hello,

I looked at this and experienced the same issue on slackware64-current (beta from sept 18) with nvidia 319.60, but only when screen is started from konsole. There's no problem when screen is started from uxterm, xterm, terminal.

Downgrading nvidia to 319.49 solves the problem.

I reinstalled nvidia 319.60, and, started Xfce. I tried screen inside konsole, and there's no issue. I returned to Kde, started screen inside konsole, and I encountered the issue again.

I also tried on slackware 14.0 with nvidia 319.60 and didn't experienced this issue.

--
SeB

guanx · 10-08-2013, 12:53 PM

Hi phenixia2003,

Thanks for your very clear description of your test result. I made a mistake in my previous tests by sometimes starting xterm/rxvt from konsole, then they inherited the signal mask of konsole.

My test result with slackware-current + NVIDIA 319.60 / 319.49 is identical to your result with slackware64-current.

bosth · 01-04-2014, 01:23 AM

I ran into this same issue as well. Disabling most Desktop Effects fixed it for me (not sure exactly which one).

slackware64-current, KDE 4.12, NVIDIA 331.20

The issue is back. Switching to tmux.