GNOME Bugzilla – Bug 710534
webdav backend segfaults for read, seek, read sequence
Last modified: 2013-12-08 11:24:26 UTC
The webdav backend consistently segfaults for a read, seek, read sequence.
Created attachment 257738 [details] [review] dav: Fix seeking on read Previously, the dav backend would segfault when reading after a seek because the stream from soup_request_send_finish() was not being stored, so store it. Fix the SEEK_END offset calculation by reversing the sign of offset and taking into account the offset of the previous seek. Ensure that the range header is updated every time ensure_request() is called in case it has been updated. Handle a read after a seek past the end of the "file" by ignoring the requested range not satisfiable http error (416) and simply returning 0.
Created attachment 263217 [details] [review] dav: Fix seeking on read Previously, the dav backend would segfault when reading after a seek because the stream from soup_request_send_finish() was not being stored, so store it. Fix the SEEK_END offset calculation by reversing the sign of offset and taking into account the offset of the previous seek. Ensure that the range header is updated every time ensure_request() is called in case it has been updated. Handle a read after a seek past the end of the "file" by ignoring the requested range not satisfiable http error (416) and simply returning 0.
The updated patch fixes the code style. CCing Dan for a review, as the original author of the code.
This should probably be several separate commits, for clarity. (In reply to comment #2) > Previously, the dav backend would segfault when reading after a seek > because the stream from soup_request_send_finish() was not being stored, > so store it. Or also if you did a read_async() without an explicit send()/send_async() first... > Fix the SEEK_END offset calculation by reversing the sign of offset and > taking into account the offset of the previous seek. Looks right > Ensure that the range header is updated every time ensure_request() is > called in case it has been updated. Looks right > Handle a read after a seek past the end of the "file" by ignoring the > requested range not satisfiable http error (416) and simply returning 0. >+ if (priv->msg->status_code == SOUP_STATUS_REQUESTED_RANGE_NOT_SATISFIABLE) >+ { >+ if (g_input_stream_close (priv->stream, NULL, &error)) >+ g_task_return_int (task, 0); >+ else >+ g_task_return_error (task, error); Ignore the error on close; the result of the read operation is "0" whether or not the close() succeeds.
Thanks for the review, Dan. Pushed as 4 separate commits (after ignoring the error on close): fbcd75035e89c9431c9e1512e02e54ac8b5200d0 http: Allow seek past end of file 7e0f96133ca897640be51c3f4039dd90188357da http: Fix the SEEK_END offset calculation 06b5820152e6b4647ef63cc2498511fbed6d4806 http: Ensure the range header is updated 0ea226568dec4ff8738c835e68dce3c98501cefb http: Fix segfault when seeking on read