Re: close() on a closed file descriptor in Visual Studio 8



On 6 Apr 2006 14:54:40 -0700, "mk" <meshko@xxxxxxxxx> wrote:

Hi,
normally closing a closed file descriptor is not a big deal, it just
returns EBADF and everybody goes on with their lives. In Visual Studio
8 it seems to throw up an assertion. I'm dealing with some code that
just goes through the file descriptor table and closes them all (pretty
typical thing to do in Unix world and OK thing to do on Windows...
until now). Would appreciate any ideas on how to change the behaviour
of close() to relax and not assert it. Is there any way to tell
whether fd is open (without digging into internal data structures of
CRT)?

Well, if you look into the CRT, you'll find the _close source does the
following:

if ( _osfile(fh) & FOPEN )

Unfortunately, neither _osfile nor FOPEN appear to be defined in the public
header files. But there may still be hope.

To suppress the assertion, see _CrtSetReportHook2 and the very important:

Report Hook Functions
http://msdn2.microsoft.com/en-us/library/74kabxyx(VS.80).aspx

To fix the problem in release mode, read the new documentation for _close:

http://msdn2.microsoft.com/en-us/library/5fzwd5ss(VS.80).aspx
<q>
This function validates its parameters. If fd is a bad file descriptor, the
invalid parameter handler is invoked, as described in Parameter Validation.
If execution is allowed to continue, the functions returns -1 and errno is
set to EBADF.
</q>

In particular, follow it to:

Parameter Validation
http://msdn2.microsoft.com/en-us/library/ksazx244(VS.80).aspx

And finally use:

_set_invalid_parameter_handler
http://msdn2.microsoft.com/en-us/library/a9yf33zb(VS.80).aspx

These methods will work. Hopefully, someone will find a _closeall function
comparable to _fcloseall that I missed and save you all this trouble. Of
course, the best thing would be to fix the code so it doesn't need to
iterate the fds. (How do you know how big the Unix-style fd table is,
anyway?)

--
Doug Harrison
Visual C++ MVP
.



Relevant Pages

  • Re: Solaris 10 - catman weird error
    ... DTrace can absolutely help in this situation. ... returns EIO or EBADF: ... probably want to know _how_ exactly the file descriptor was closed. ... that you know the process ID of the problematic process, here is a D script ...
    (comp.unix.solaris)
  • Possible error in Beejs guide to IPC document
    ... My query is for Unix IPC. ... I think he meant to say fcntl() will return EBADF. ... accept the path and returns a file descriptor which we input to fcntl ...
    (comp.unix.programmer)
  • Re: [RFC/PATCH] revoke/frevoke system calls V2
    ... As a bonus, ... it works for regular files and even goes as far as destroying ... "EBADF" is not something that applications are taught to expect. ... Someone correct me if I'm wrong, but I can think of no situation under which a file descriptor currently gets yanked out from under your feet -- you should always have to formally abandon it with close. ...
    (Linux-Kernel)
  • Re: Bad file descriptor error
    ... It may mean that google has summarily hung up on you. ... EBADF occurs, if the file descriptor is invalid. ...
    (comp.lang.ruby)
  • close() on a closed file descriptor in Visual Studio 8
    ... returns EBADF and everybody goes on with their lives. ... In Visual Studio ... it seems to throw up an assertion. ... just goes through the file descriptor table and closes them all (pretty ...
    (microsoft.public.vc.language)