daveb@laidbak.UUCP (Dave Burton) (12/24/87)
The following program produces disconcerting output on
a Tandy 6000 with 3.2 Xenix Core, 3.0 Development System:
main()
{
setpgrp();
if (fork() == 0)
printf(" child: pid = %d pgrp = %d\n", getpid(), getpgrp());
else
printf("parent: pid = %d pgrp = %d\n", getpid(), getpgrp());
}
Tandy 6000: [cc ...]
parent: pid = 9536 pgrp = 9536
child: pid = 9537 pgrp = 9537
^^^^----!!!
Sun 3/160, 3.4 SunOS: [/usr/5bin/cc ...]
parent: pid = 1074 pgrp = 1074
child: pid = 1074 pgrp = 1074
A somewhat more serious bug is illustrated in the following
code:
/* Bach, pg. 211 */
#include <signal.h>
main()
{
register int i;
setpgrp();
for (i = 0; i < 10; i++) {
if (fork() == 0) {
if (i & 1) setpgrp();
printf("pid = %d pgrp = %d\n", getpid(), getpgrp());
pause();
}
}
kill(0, SIGINT);
}
The Tandy produces a newline and no children!
[cc ...]
The Sun works, sortof. It spits out 7 lines of info
(because no exit()) and leaves only 4 orphans.
[/usr/5bin/cc ...]
A Sequent works properly, giving 10 output lines
and 5 orphans.
[att cc ...]
What gives?
How many other inconsistencies are there in the Xenix kernel?
Do the 3.1 and earlier versions exhibit the same behaviour?
--
--------------------"Well, it looked good when I wrote it"---------------------
Verbal: Dave Burton Net: ...!ihnp4!laidbak!daveb
V-MAIL: (312) 505-9100 x325 USSnail: 1901 N. Naper Blvd.
#include <disclaimer.h> Naperville, IL 60540uhclem@trsvax.UUCP (12/31/87)
/* Written 9:48 am Dec 29, 1987 by hal6000.UUCP!iv in trsvax:comp.sys.tandy */ /* Written 10:50 pm Dec 23, 1987 by laidbak!daveb in comp.sys.tandy */ |* ---------- "Tandy 3.2 kernel bug?" ----------------- */ | The following program produces disconcerting output on | a Tandy 6000 with 3.2 Xenix Core, 3.0 Development System: | main() | { | setpgrp(); | if (fork() == 0) | printf(" child: pid = %d pgrp = %d\n", getpid(), getpgrp()); | else | printf("parent: pid = %d pgrp = %d\n", getpid(), getpgrp()); | } \* ---------- End of quote from comp.sys.tandy --------- */ Well, with a modified version of the above program, I duplicated the problem. Boy, this is an ancient bug. This has been around since 3.0! My version: main() { setpgrp(); if (fork() == 0) printf(" child: pid = %d pgrp = %d\n", getpid(), getpgrp()); else { sleep(1); /* Make sure parent hangs around for child */ printf("parent: pid = %d pgrp = %d\n", getpid(), getpgrp()); } } By the way, your second program doesn't always work because the parent can kill the children before they've had a chance to run. Insert a sleep(5) in before the kill(0, SIGINT). The problem was not in the kernel, it was in the library. What was happening was setpgrp() and getpgrp() were not putting enough arguments on the stack for the kernel, and so the kernel was looking at someone's return address instead of the intended argument to the system call. The result of this confusion was that getpgrp() thought that it was setpgrp(), and so it did. To fix the problem, run the following shell script as root, and then relink any programs using getpgrp() [by a quirk of core trash, setpgrp() works]. : Run me with "sh -e", not "csh -e" # # The output of this script should be the following: # x - setpgrp.o # _getpgrp: 0x2F3C = 0x7000 # _getpgrp+2: 0x0 = 0x2F00 # _getpgrp+4: 0x0 = 0x2F00 # _getpgrp+12: 0x588F = 0x508F # _setpgrp: 0x2F3C = 0x7001 # _setpgrp+2: 0x0 = 0x2F00 # _setpgrp+4: 0x1 = 0x2F00 # _setpgrp+12: 0x588F = 0x508F # r - setpgrp.o # cd /lib ar xv libc.a setpgrp.o adb -w setpgrp.o << ! _getpgrp?w 0x7000 0x2f00 0x2f00 _getpgrp+12?w 0x508f _setpgrp?w 0x7001 0x2f00 0x2f00 _setpgrp+12?w 0x508f ! ar uv libc.a setpgrp.o rm setpgrp.o exit 0 ---- [This information was provided by an individual and is not nor should be construed as being provided by Radio Shack or Tandy Corporation. Radio Shack and/or Tandy Corporation have no obligation to support the information provided. They might get around to it in a couple of years. The author will, however, cheerfully accept xmail. This note will self- destruct in 5 seconds. Good luck, %s.] IV (aka John Elliott IV) Domain: iv@hal6000.Tandy.COM 1300 Two Tandy Center UUCP: ...!ihnp4!sys1!hal6000!iv Tandy Systems Software or: ...!decvax!microsoft!trsvax!hal6000!iv Fort Worth, TX 76102 Phone: 817/390-2701; 9:30am-6:00pm CST /* End of text from trsvax:comp.sys.tandy */