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

file-descriptor probs.

From: Ben Collins-Sussman <sussman_at_collab.net>
Date: 2001-09-19 21:46:38 CEST

So I've got a bug in libsvn_ra_dav/commit.c:commit_stream_close().

ra_dav's commit editor (apply_textdelta) dumps svndiff data into a
tmpfile. When the textdelta stream is closed, this routine is
automatically called; it tells neon to "pull" the file's data in order
to do a PUT.

The old system (which worked):
--------------

  * The tmpfile is an apr_file_t that used to be created directly by
    ra_dav.

  * in commit_stream_close,
 
        - the tmpfile was apr_file_close()d.
        - it was reopened using fopen(tmpfile-name)
        - a filedescriptor was passed to neon using fileno()
        - a call to fclose(), and then apr_remove_file(tmpfile-name)

The new system
--------------

  * The tmpfile is created by libsvn_client; ra_dav invokes a
    callback, and the client returns only an apr_file_t that has
    *already* been unlinked. (APR_DELONCLOSE).

  * in commit_stream_close,

        - the apr_file_t is rewound using apr_file_seek()
        - the filedescriptor is discovered using apr_os_file_get()
        - filedescriptor passed to neon
        - apr_file_close(tmpfile)

The bug I'm seeing is that the PUT is hanging forever; gdb indicates
that ne_begin_request is blocking infinitely in sock_readline
(select()).

My assumption is that somehow the filedescriptor isn't being rewound?
Maybe? Although apr_file_seek is definitely calling lseek() under the
hood, and it's return value indicates the position is back at 0.

Joe, any ideas?

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sat Oct 21 14:36:41 2006

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