Date: Mon, 9 Oct 1995 14:51:01 +0800 From: Peter Wemm sfjhgsd fhasldf kjahs <peter@jhome.DIALix.COM> To: FreeBSD-gnats-submit@freebsd.org Subject: ports/773: screen-3.6.2 from -current wont work... Message-ID: <199510090651.OAA10701@jhome.DIALix.COM> Resent-Message-ID: <199510090730.AAA27548@freefall.freebsd.org>
next in thread | raw e-mail | index | archive | help
>Number: 773
>Category: ports
>Synopsis: screen-3.6.2 from -current wont work...
>Confidential: no
>Severity: serious
>Priority: medium
>Responsible: freebsd-bugs
>State: open
>Class: sw-bug
>Submitter-Id: current-users
>Arrival-Date: Mon Oct 9 00:30:02 PDT 1995
>Last-Modified:
>Originator: Peter Wemm sfjhgsd fhasldf kjahs
>Organization:
DIALix
>Release: FreeBSD 2.2-CURRENT i386
>Environment:
-current kernel, near -current binaries (less than 1 week old), -current ports.
FreeBSD jhome.DIALix.COM 2.2-CURRENT FreeBSD 2.2-CURRENT #60: Fri Oct 6 05:23:45 WST 1995 peter@jhome.DIALix.COM:/home/src/sys/compile/JHOME i386
>Description:
If screen is installed with the default permissions (setuid-root), it core
dumps with a bus error if run as a mortal user, and locks up the
tty if run as root. In both cases, a child process sits in a 100%
cpu busy loop, while the parent dies.
>How-To-Repeat:
make install
rehash
screen
>Fix:
I really do not know.. I looked at the code where it's dying, and
it looks really odd. It almost looks like gcc is mis-compiling the
code, but I could easily be wrong.
It is dying in one of several areas I have seen, mostly inside:
for (display = displays; display; display = display->next) {
if (D_status == 0)
continue;
....
}
D_status is a macro for display->d_status. Somehow, at the point of
death, it is dereferencing a NULL display variable inside the
D_status test. I do not see how it could be doing that.. I must be
missing something obvious.
The only other thing I can think of, is the MD5 passwords. The port
is most definately at -current level, and the patch that increases
the string to 30 is present. It is dying when it has read access to
master.passwd and the encrypted strings.
I have still got more things to try yet, but last time I looked at
it, ktrace paniced the system. I'm waiting for the next ctm mailout.
I did notice that pass2() in process.c can assemble the encrypted
string into "Password" *without* the null terminating character.
>Audit-Trail:
>Unformatted:
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199510090651.OAA10701>