Re: SIGSEGV on fclose.

From: Mads Bondo Dydensborg (madsdyd@challenge.dk)
Date: Thu Jul 13 2000 - 04:30:29 EST


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/



This archive was generated by hypermail 2b29 : Sat Jul 15 2000 - 21:00:16 EST