Messages in this thread | | | Date | Thu, 13 Jul 2000 11:30:29 +0200 (CEST) | From | Mads Bondo Dydensborg <> | Subject | Re: SIGSEGV on fclose. |
| |
On Thu, 13 Jul 2000, David Woodhouse wrote:
> > bbl@dk.damgaard.com said: > > in case you wonder: the problem arises from a program that closes a > > file twice because it does not know that the file is allready closed. > > Don't do that then. > > Read the man page: > ... any further access (including another call to fclose()) to > the stream results in undefined behaviour. > > Returning SIGSEGV is permitted as 'undefined behaviour'. Just consider > yourself lucky it didn't format your hard drive, pee on the carpet, and/or > start global thermonuclear war.
I would think - from reading the manpage - that it should return EBADF from the test program Bjarne posted. I tried this on HPUX, and as he says, it does not segfault there.
The manpage says:
ERRORS EBADF The argument stream is not an open stream.
I do not know a lot about the Linux file system, but I found this in fs/open.c:
/* * Careful here! We test whether the file pointer is NULL before * releasing the fd. This ensures that one clone task can't release * an fd while another clone is opening it. */ asmlinkage int sys_close(unsigned int fd) { int error; struct file * filp;
lock_kernel(); error = -EBADF; filp = fcheck(fd); if (filp) { struct files_struct * files = current->files; files->fd[fd] = NULL; put_unused_fd(fd); FD_CLR(fd, files->close_on_exec); error = filp_close(filp, files); } unlock_kernel(); return error; }
I do not know how it get the relation between fd and the call to fclose. Could this be a glibc-on-linux thing? In what cases would one expect it to return EBADF if not in this?
Mads
-- Mads Bondo Dydensborg. madsdyd@challenge.dk You know you're a Linux geek when...
You find the thought of rebooting after installing a piece of software utterly absurd. - segfault
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/
| |