jim (09/21/82)
Why does our uucico quit with a core dump in the middle of a session? I have heard that this will happen when you have too many files in your uucp spool directory, but this happens to us and several of our 4.1bsd neighbors with less than a day's accumulation of Usenet (less than 100 D files). On a different subject, when inews is posting news to another site, why doesn't it have uux use the original copy of the news articles from the news spool directory instead of making a copy in the uucp spool directory? Is this possible? It would cut down on the number of files in the uucp spool directory. Jim Rees ...!ucbvax!lbl-unix!uw-beaver!jim ...!decvax!microsoft!uw-beaver!jim Jim@Washington (Arpanet)
jim (09/22/82)
Never mind, I found it. In anlwrk.c, routine iswrk(), the line if (listp == NULL || *listp == NULL || listp > (list + LLEN) should read if (listp == NULL || *listp == NULL || listp >= (list + LLEN) Otherwise it will crash when it gets to the LLEN+1th work file. Before I could find this, I had to fix intrEXIT() in cico.c. In 4.1bsd, a call to abort() does not result in a SIGIOT. I don't know what it does result in, and I suppose it could change some time, so I reset all the signals by changing signal(i, SIG_DFL); to int i; for (i=1; i<16; i++) signal(i, SIG_DFL); I guess it would be better to explicitly name all the signals in case some other Unix doesn't number them 1-15, but I'm basically lazy. Before I made this fix, the call to abort() resulted in some signal, which called intrEXIT(), which didn't reset the signal but did cause another. This gave a vicious recursive cycle and it didn't actually quit until it ran out of stack space (512K on our system). I assume some one else has already tracked down these bugs and other equally offensive ones. Could someone please send me the rest of the fixes?