[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: [PATCH] Duplicate close of file handle on WIN32

From: <rbb_at_rkbloom.net>
Date: 2003-02-01 21:22:42 CET

On Sat, 1 Feb 2003, [UTF-8] Branko Čibej wrote:

> rbb@rkbloom.net wrote:
>
> >Why is SVN registering a cleanup in this code at all? The comment says
> >that we have to close the file when the apr_file_t goes away, but the
> >apr_file_t already has a cleanup in it.
> >
>
> Because on Windows, a file descriptor (int) suitable for use by the
> POSIX-like file I/O functions is *not* the same thing as a file handle
> (HANDLE, apr_os_file_t) that APR uses internally to call the Win32 file
> I/O functions. We need a file descriptor to pass to Neon; that's why we
> call _open_osfhandle. (That function is somewhat similar to fdopen, on a
> lower level.)
>
> If we don't close the file descriptor, we'll leak it, and file
> descriptors (which are created by the C runtime, not the OS) are a
> _very_ limited resource, unlike file handles. Duplicating the handle
> before calling _open_osfhandle seems like an acceptable way to avoid the
> double-close bug.
>
> An even better solution woudl be to remove the pool cleanup for the
> apr_file_t, but we can't safely do that (it might be doing other things
> besides closing the handle).

Even better than that would be to fix APR so that it registers the proper
cleanups in this case. This still confuses me though. The problem that
is being reported, is that we are closing the file twice. Once by the
cleanup that APR registers, and once by the cleanup that SVN registers.
So, what exactly is the SVN cleanup supposed to be doing? The APR cleanup
seems to be closing the file correctly, otherwise their wouldn't be a bug
report.

Ryan

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sat Feb 1 21:11:15 2003

This is an archived mail posted to the Subversion Dev mailing list.