On 7. 9. 25 22:38, Daniel Sahlberg wrote:
Den ons 20 aug. 2025 kl 16:43 skrev Branko Čibej <br...@apache.org>:
[moved here from users@]
On 20. 8. 25 14:29, sebb wrote:
svn co --depth=emptyhttps://svn.apache.org/repos/asf/incubator
Traced this to svn_ra_serf__expect_empty_body() line 1154; the
value returned from serf_bucket_response_get_headers() is 0xf0,
clearly wrong, and then serf_bucket_headers_get() crashes. This
happens with both serf-1 and serf-2 (trunk), could be a bug in
Serf, could be something else. Also happens over http://, so it's
not something related to OpenSSL (which makes sense).
-- Brane
Hi,
I've spent some time this weekend trying to figure this out. It seems
like we end up in Subversion's libsvn_ra_serf/update.c in
process_buffer with at_eof = 0, thus creating an EAGAIN bucket which
doesn't have any header, thus causing an error later on (as described
by Brane above). Thus I'm leaning towards a Subversion error rather
than an error in Serf.
The call originates in update_delay_handler and it seems that function
has the proper headers in the request bucket. But it creates a new
bucket in process_buffer, without attaching the headers. This in turn
causes the issues in serf_bucket_response_get_headers() since there
are no headers to get.
I'm a bit at loss here, but it would be fun to be able to follow this
to the very end so if I may ask the graybeards here to not "just solve
it" but bear with me and maybe just give me a few pointers on where to
look next. Even if it is a Doh! moment for someone...
Never been in that code. If it's a 301, Subversion should handle it, I'm
almost certain Serf doesn't (which is ... another kind of problem).
You're sure it behaves as if it received EAGAIN instead of a redirect? I
know there's code in Subversion that handles redirects, but it's IIRC at
a higher level where we connect to the repository; not in the edit drive.
-- Brane
