[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: Branko Čibej <brane_at_xbc.nu>
Date: 2003-02-01 01:43:56 CET

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).

> This means that the cleanup
>registered by svn is superfluous. Just remove that line and this problem
>should go away.
>Also, there is a FIXME in that code that talks about getting a pool from
>an APR type. While that line should just go away for the reasons given
>above, any other lines like that should be changed to apr_foo_pool_get().
Ah, right. Thanks for the tip.

>On Fri, 31 Jan 2003, Patrick Mayweg wrote:
>>when a file descriptor is needed for neon the function
>>svn_io_fd_from_file is called. On WIN32 it creates a file descriptor
>>from the Win32-Handle. It also registers a cleanup function to close the
>>file descriptor. This also closes the Win32-Handle, which is also closed
>>for the apr-file. This is one closeing too many. Only if you run svn in
>>a debugger, this problem shows up. The right thing to do is to duplicate
>>the handle. I have written a patch for that and it fixes my problem.
>>* ./subversion/libsvn_subr/io.c
>> (svn_io_fd_from_file) Added call to DuplicateHandle
>>Index: subversion/libsvn_subr/io.c
>>--- subversion/libsvn_subr/io.c (revision 4685)
>>+++ subversion/libsvn_subr/io.c (working copy)
>>@@ -1674,7 +1674,15 @@
>> #ifndef SVN_WIN32
>> *fd_p = fd;
>> #else
>>- *fd_p = _open_osfhandle ((long) fd, _O_RDWR);
>>+ apr_os_file_t fd2 = 0;
>>+ if (DuplicateHandle (GetCurrentProcess(), fd, GetCurrentProcess(),
>>+ (LPHANDLE)&fd2, 0, FALSE,
>>+ {
>>+ status = APR_EBADF;
>>+ return status;
>>+ }
>>+ *fd_p = _open_osfhandle ((long) fd2, _O_RDWR);
>> /* We must close the file descriptor when the apr_file_t is
>> closed, otherwise we'll run out of them. What happens if the
>>Patrick Mayweg
>>To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
>>For additional commands, e-mail: dev-help@subversion.tigris.org
>To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
>For additional commands, e-mail: dev-help@subversion.tigris.org

Brane Čibej   <brane_at_xbc.nu>   http://www.xbc.nu/brane/
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sat Feb 1 01:44:36 2003

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

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.