Bug 241750 - sysutils/screen: Hangs at startup after upgrade from 4.7.0_1 to 4.7.0_4
Summary: sysutils/screen: Hangs at startup after upgrade from 4.7.0_1 to 4.7.0_4
Status: Closed FIXED
Alias: None
Product: Ports & Packages
Classification: Unclassified
Component: Individual Port(s) (show other bugs)
Version: Latest
Hardware: Any Any
: --- Affects Some People
Assignee: Cy Schubert
Keywords: needs-qa, regression
Depends on:
Reported: 2019-11-06 04:00 UTC by Victor Sudakov
Modified: 2020-04-05 21:17 UTC (History)
2 users (show)

See Also:
koobs: maintainer-feedback? (cy)
koobs: merge-quarterly?


Note You need to log in before you can comment on or make changes to this bug.
Description Victor Sudakov 2019-11-06 04:00:10 UTC
After upgrade to 4.7.0_4 screen would not start: it just hangs after start. A rollback to screen-4.7.0_1 fixes the problem. The system is 11.3-RELEASE.

Compile options:

Options        :
        INFO           : on
        NAMED_PIPES    : off
        NCURSES_BASE   : off
        NCURSES_PORT   : off
        NETHACK        : on
        SHOWENC        : off
        SOCKETS        : on
        XTERM_256      : on
Comment 1 Kubilay Kocak freebsd_committer freebsd_triage 2019-11-06 04:07:48 UTC
Thank you for the report Victor. If there are non-default OPTIONS selected for this build, please try the default options (make rmconfig) and let us know if the issue is still reproducible

^Triage: Fix Summary typo, assign to maintainer
Comment 2 Victor Sudakov 2019-11-06 04:52:21 UTC
I've double checked, these ARE the default options.

It is also not locale-related, the problem is there both with ru_RU.KOI8-R and ru_RU.UTF-8
Comment 3 Victor Sudakov 2019-11-06 05:52:43 UTC
Just tried recompiling with NAMED_PIPES instead of SOCKETS, it did not help however.

^T shows that it's just in the pause state:

$ screen
load: 0.08  cmd: screen 40879 [pause] 2.44r 0.00u 0.01s 0% 2624k
load: 0.06  cmd: screen 40879 [pause] 21.39r 0.00u 0.01s 0% 2624k

^C does not interrupt it. ^Z can send it into background, but "fg" does not bring it back:

$ screen

load: 0.35  cmd: screen 40912 [pause] 4.32r 0.01u 0.00s 0% 2624k

$ fg
Sorry, cannot contact session "40913.pts-1.pager1" again.

Comment 4 Cy Schubert freebsd_committer 2019-11-06 06:19:05 UTC
uname -a please.

Try sending kill -cont to the screen PIDs.
Comment 5 Victor Sudakov 2019-11-06 12:36:28 UTC
(In reply to Cy Schubert from comment #4)
> uname -a please.

You know what! The bug is present on i386 only! I've set up two otherwise identical VMs in bhyve. 

Here the bug is NOT present:

FreeBSD test4.sibptus.ru 11.3-RELEASE-p3 FreeBSD 11.3-RELEASE-p3 #0: Mon Aug 19 21:08:43 UTC 2019     root@amd64-builder.daemonology.net:/usr/obj/usr/src/sys/GENERIC  amd64

Here the bug is present:

FreeBSD test3.sibptus.ru 11.3-RELEASE-p3 FreeBSD 11.3-RELEASE-p3 #0: Mon Aug 19 21:02:24 UTC 2019     root@amd64-builder.daemonology.net:/usr/obj/usr/src/sys/GENERIC  i386
Comment 6 Victor Sudakov 2019-11-06 12:39:20 UTC
(In reply to Cy Schubert from comment #4)
> Try sending kill -cont to the screen PIDs.

vas@test3:~ % ps axwwu | grep screen
vas   1723   0,0  0,3  6912 2784  0  S+   19:37    0:00,01 screen
vas   1731   0,0  0,2  6200 2076  1  S+   19:38    0:00,00 grep screen
vas@test3:~ % kill -CONT 1723
1723: Operation not permitted
vas@test3:~ % 

(that was from another SSH session).
Comment 7 Victor Sudakov 2019-11-06 12:41:40 UTC
(In reply to Victor Sudakov from comment #6)
The same "kill -CONT 1723" - just nothing happens. screen keeps haning in the [pause] state.

Would you like an account on that i386 virtual host?
Comment 8 Victor Sudakov 2019-11-06 12:43:27 UTC
(In reply to Victor Sudakov from comment #7)
> The same "kill -CONT 1723" - just nothing happens

I meant the above from root, from another SSH session.
Comment 9 commit-hook freebsd_committer 2019-11-06 21:18:11 UTC
A commit references this bug:

Author: cy
Date: Wed Nov  6 21:17:25 UTC 2019
New revision: 516926
URL: https://svnweb.freebsd.org/changeset/ports/516926

  Circumvent a hang on FreeBSD 11 i386 caused by an unreported (only visible
  through truss) stack assertion.

  This is a temporary fix which will require further investigation to
  determine the cause.

  PR:		241750
  Reported by:	Victor Sudakov <vas@sibptus.ru> (in the PR)
  		Paul Beard <paulbeard@gmail.com> (via direct email)

Comment 10 Cy Schubert freebsd_committer 2020-04-05 21:17:09 UTC