ber (06/02/82)
#N:harpo:6300001:000:213 harpo!ber Jun 1 22:44:00 1982 Almost everytime I look in /usr/spool/uucp there is a core file from uucico. When I use adb to look at the calling trace it says: sigtramp() Anyone know what this means. I'm sure it's obvious. brian redman
ld@sri-unix (06/04/82)
I have seen a similar problem. It seems to be of recent origin (possibly
related to netnews or a new 9600 baud connection?). When I print the stack
using adb I get the following:
.
.
.
.
_intrEXIT(4,1,f7c) from fa0
sigtramp(4,1,f7c) from 7ffff077
_calloc() from 7562
_intrEXIT(4,1,f7c) from fa0
sigtramp(4,1,f7c) from 7ffff077
_calloc() from 7562
_intrEXIT(b,0,f7c) from fa0
sigtramp(b,0,f7c) from 7ffff077
_prefix(7fffee36,2e4400a8) from 5a4b
_iswrk(a540,b9c4,a3e6,7fffee35) from 62e6
_gtwvec(a540,a3e6,7fffee35,7fffe0f8) from 63be
_cntrl(1,7fffee35) from 10b8
_main(1,7fffee84,7fffee8c) from be7
Prefix() is essentially strcmp(). Upon examining 7fffee36 and 2e440a8,
I find that 7ff... is a valid string pointer but 2e... is data from a string.
Looking in iswrk(), I found that there was a static array of pointers to
strings with a dimension of 20. A pointer to this table is indiscriminantly
incremented without checking for table overflow:
sprintf(file, "%s/%s", dir, *listp++);
While I am not sure that this is the line that causes the failure, I noted that
the pointer had indeed been incremented beyond the bounds of the array.
At this point I had to quit hacking and get back to work, so I cannot offer the
solution. Hopefully, this note will help someone else find the bug.
Larry Dwyer
Hewlett Packard Co.
Cupertino, CA.
..!ucbvax!hpda!ld
PS: Do not believe the return address netnews posts. I am not `@ sri-unix'.essick (06/09/82)
#R:harpo:6300001:uiucdcs:18600002:000:931
uiucdcs!essick Jun 4 12:31:00 1982
We had this problem about a month ago. Uucp would establish
a connection to a machine, send about a dozen files or so and then
core dump.
Looking at /usr/spool/uucp showed that there where several
hundred C* files. It turns out that the array "wrkvec" is only
dimensoned to 20. Apparently, we would wind up overrunning the
array, stomp all over other variables (and probably the rest of the
stack frame) and that was the end.
Our "solution" has worked fine for us. We upped the wkrvec to
1000 elements and have not had this problem since.
While looking for this "bug", I never saw anything that watches
the end of the array to see if the program is about to go off the end.
Did I miss it? or is the program never supposed to work itself into
a situation like that?
Ray Essick
pur-ee!uiucdcs!essick
107c107
< char filename[MAXFULLNAME], wrktype, *wrkvec[1000];
---
> char filename[MAXFULLNAME], wrktype, *wrkvec[20];lepreau (06/10/82)
Well, I wouldn't want to bet on this, but I think you
might have just gotten lucky. Blowing up with many C. files sounds
as if it's the off-by-one bug in iswrk() which was reported long
ago by Alan Watt & Art Feather (tho their fix had a typo):
< if (listp == NULL || *listp == NULL || listp > (list + LLEN)
---
> if (listp == NULL || *listp == NULL || listp >= (list + LLEN)
Have you installed this?
It looks to me as if wrkvec is only filled by the getargs routine when
parsing a single line of a C. file, and I don't think a C. file can get
anywhere near 20 fields. Unless getargs is buggy...
BTW, the anlwrk.c inefficiency that utzoo!henry reported has been largely
fixed in the distributed 4.1bsd version; the loop is exited properly and LLEN
is 20. Making it bigger yet ought to cut down on the amount of news and
mail delivered out of order.
-jay lepreausalkind (06/10/82)
The fix posted (for the bug in anlwrk.c) is not quite right. Here is a correct one line fix (around line 67): if (listp == NULL || listp >= (list + LLEN) || *listp == NULL Note the order of the tests is reversed also. Lou Salkind