ok@edai.UUCP (01/22/84)
Every time I (try to) use the 'r'eply option of readnews, I arrive
safely back at readnews prompt level having correctly produced a
/tmp/pn????? file, and a few seconds later get a message on the screen
"sh: bus error, core dumped" or something like that. I finally got
annoyed enough to track the problem down.
recmail.c has a section which looks roughly like this:
FILE *fd;
char *tmpf;
char linebuf[1024];
...
tmpf = mktemp("/tmp/rmXXXXXX");
fd = fopen(tmpf, "w");
while (fgets(linebuf, sizeof linebuf, stdin) != NULL) {
fputs(linebuf, fd);
...
The immediate cause of the problem is the fputs call: fd is NULL!
I am not all that charmed by recmail's failure to check that the fopen
call worked. I am totally bewildered by the fact that fopen sometimes
returns NULL here. The call to mktemp has in fact come up with a file
name which I can create. I have tried to make this program fail on its
own, and I can't. The only thing I can think of is *maybe* it is called
from some process which has tied up all the channels available and isn't
closing them when it forks?
In any case, does anyone know how to fix this problem? (We're
running 4.1bsd in case it matters.)
There's another problem with this version of recmail: it never ever
removes the /tmp/rm?????? file it creates. The only thing that stops it
clogging up /tmp is that it never succeeds in creating the file. Or is
there a hack for that in some other program in the news suite? Just for
completing ones losses, the /tmp/pn????? file IS removed, so that if you
want to mail the article by hand, you have to re-enter it. Nice one!scw@cepu.UUCP (01/31/84)
*<- dead bug
recmail.c has a section which looks roughly like this:
FILE *fd;
char *tmpf;
char linebuf[1024];
...
tmpf = mktemp("/tmp/rmXXXXXX");
+ close(creat(tmpf,0666));
fd = fopen(tmpf, "w");
while (fgets(linebuf, sizeof linebuf, stdin) != NULL) {
fputs(linebuf, fd);
...
> The immediate cause of the problem is the fputs call: fd is NULL!
>I am not all that charmed by recmail's failure to check that the fopen
>call worked. I am totally bewildered by the fact that fopen sometimes
>returns NULL here. The call to mktemp has in fact come up with a file
>name which I can create. I have tried to make this program fail on its
>own, and I can't. The only thing I can think of is *maybe* it is called
>from some process which has tied up all the channels available and isn't
>closing them when it forks?
The problem arrises from the case that fopen won't create the file for you
(at least on some versions of unix). My copy of readnews had the same problem
I fixed it very easily by putting the following line in front of the offending
fopen.
close(creat(tmpf,0666));
This needs to be done at 2 locations in readnews (in the readr.c file
follow_up_command near line 859, and in reply_command near line 670).
(See above). This fix is applicable to anyplace that you have an
fopen(tmp,...) and are not sure that the file already exsists. if you
want to be VERY sure (you think that the file may not be openable) you
can use:
int cre_ok;
...
cre_ok=creat(tmpf,0666);
if(cre_ok < 0){
perror(tmpf);
...error processing...
}
else {
close(cre_ok);
fd=fopen(tmpf,"w");
...process tmpf...
unlink(tmpf);
}
--
Stephen C. Woods (VA Wadsworth Med Ctr./UCLA Dept. of Neurology)
uucp: ...{ hao, trw-unix, sdcsvax!bmcg}!cepu!scw ARPA: cepu!scw@ucla-locus
location: N 34 06'37" W 118 25'43"