dmmartindale (11/07/82)
There may be a bug in a more recent version of uuxqt that some USENET sites may be running. If your uuxqt.c doesn't try to separate the exit status of the commands it runs into an exit status and signal number, then you don't have the bug (look at the line following the call to shio()). However, if your uuxqt does this, check to make sure that it labels the two fields correctly - it was reversed here. This may have been my own typo when installing the change, or it may be wrong at other sites too. This is the correction I made: Dave Martindale *** /u/dmmartindale/old/uuxqt.c Sun Nov 7 13:25:44 1982 --- /usr/src/cmd/uucp/uuxqt.c Sun Nov 7 13:31:15 1982 *************** *** 171,177 mvxfiles(xfile); chdir(XQTDIR); ret = shio(buf, fin, dfile, user); ! sprintf(retstat, "exit %d, signal %d", ret&0377, (ret>>8)&0377); if (strcmp(xcmd, "rmail") != SAME && notiok && (!nonzero || (nonzero && ret != 0))) notify(user, Rmtname, cmd, retstat); --- 171,177 ----- mvxfiles(xfile); chdir(XQTDIR); ret = shio(buf, fin, dfile, user); ! sprintf(retstat, "signal %d, exit %d", ret&0377, (ret>>8)&0377); if (strcmp(xcmd, "rmail") != SAME && notiok && (!nonzero || (nonzero && ret != 0))) notify(user, Rmtname, cmd, retstat);
scw@cepu.UUCP (05/25/84)
There is a bug in uuxqt.c involving *LONG* mail paths, or long command lines;
SYSTEMS Affected:
v7, v7m, Ultrix-11(??), 2.8BSD, 2.9BSD(??); Anyone with v7 derived
uucp (?probably);
Symptoms:
uuxqt (UUXQT) vanishes leaving LCK.XQT and a 0 length core in
/usr/spool/uucp or a real core file (depending on who actually invoked
it and the permisions on /usr/lib/uuxqt) that has the C back frames
scrogged.
Cause:
While parsing the command line the mail path (argument to rmail)
tramples on the stack. Actually it gets copied to a char[] that is
too short.
Repeat by:
Send a message with more that MAXFULLNAME (uucp.h) characters in the
path. A system with this problem will be unable to pass the message on.
-or-
Generate a bogus X.system1234 file with a long (>MAXFULLNAME) X line
in it. then manually invoke uuxqt with -x4 to watch it die with a
segementation violation.
Fix:
change line ~~40 from:
char xcmd[100];
to:
char xcmd[BUFSIZ];
Change line ~~50 from:
char *cmdp, prm[MAXFULLLNAME],*ptr;
to:
char *cmdp, prm[BUFSIZ],*ptr;
This fix will allow command lines to be up to 511 char long.
--
Stephen C. Woods (VA Wadsworth Med Ctr./UCLA Dept. of Neurology)
uucp: { {ihnp4, uiucdcs}!bradley, hao, trwrb, sdcsvax!bmcg}!cepu!scw
ARPA: cepu!scw@ucla-locus location: N 34 06'37" W 118 25'43"scw@cepu.UUCP (05/25/84)
There is a bug in uuxqt.c involving very long execute times (with many executes)
SYSTEMS Affected:
v7, v7m, Ultrix-11(??), 2.8BSD, 2.9BSD(??); Anyone with v7 derived
uucp (?probably);
Symptoms:
Several copies if uuxtq run simultaniously.
Cause:
uuxtq doen't update the lock (LCK.XQT) between processes.
Repeat by:
Exec several files (so that total execute time is longer than
the X_LOCKTIME (uucp.h). This can happen if you get several
days worth of news into your system when it's very busy.
Fix:
Make the following changes to uuxqt.c to update X_LOCK just before
every search/execute cycle.
--- uuxqt.c.B Wed Jan 18 13:13:04 1984
*** uuxqt.c Thu May 24 13:18:25 1984
***************
--- 50,55 -----
char *getprm();
int uid, ret;
int stcico = 0;
Debug = 0;
*** 50,56
int uid, ret;
+ long now,timep[2]; /* to update lock file*/
int stcico = 0;
***************
--- 81,86 -----
while (gtxfile(xfile) > 0) {
DEBUG(4, "xfile - %s\n", xfile);
xfp = fopen(xfile, "r");
ASSERT(xfp != NULL, "CAN'T OPEN %s", xfile);
*** 83,91
while (gtxfile(xfile) > 0) {
DEBUG(4, "xfile - %s\n", xfile);
+ time(&now); /* get time */
+ timep[0]=timep[1]=now; /* set up table */
+ utime(X_LOCK,timep); /* and fix lock time up*/
xfp = fopen(xfile, "r");
ASSERT(xfp != NULL, "CAN'T OPEN %s", xfile);
--
Stephen C. Woods (VA Wadsworth Med Ctr./UCLA Dept. of Neurology)
uucp: { {ihnp4, uiucdcs}!bradley, hao, trwrb, sdcsvax!bmcg}!cepu!scw
ARPA: cepu!scw@ucla-locus location: N 34 06'37" W 118 25'43"steve@tellab3.UUCP (Steve Harpster) (05/31/84)
The following is a bug I discovered yesterday which caused our uuxqt to die. I am reletively new to the net so if this bug has been already hashed out, I apologize. Subject: Uuxqt hangs Index: usr.bin/uucp/uuxqt.c 4.2BSD Description: Uuxqt dies with an ASSERT XQTDIR ERROR when an execute file has a name greater than 14 characters. When in debug mode, the full pathname of the execute file shown is garbage. Repeat-By: uux host!cmd very_long_filename Fix: The problem is in mvxfiles() in the file uuxqt.c. This is where the execute files are moved into XQTDIR. Notice that the line if (sscanf(&buf[1], "%s%s", ffile, tfile) < 2) doesn't restrict the length of ffile or tfile. Tfile is declared to be a character array of length NAMESIZE (== 15). This is fine on older versions of Unix where the maximum name of a file was guaranteed to be less than or equal to 14; however, in 4.2bsd, filenames can be up to 255 (see MAXNAMLEN in dir(5)). This results in blowing out the array tfile thereby corrupting tfull (which holds the full pathname of the execute file. My fix was to simply change the define NAMESIZE in uucp.h from 15 to 255. I suppose you should also up MAXFULLNAME which is currently set to 250 but that really seems ok for now (at least for us).