From: utzoo!decvax!cca!hplabs!hpda!ld@sri-unix Newsgroups: net.bugs.uucp Title: Re: sigtramp() - (nf) Article-I.D.: hpda.161 Posted: Thu Jun 3 19:07:17 1982 Received: Sun Jun 13 02:30:11 1982 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'.