On 1. 1. 26 12:59, Daniel Sahlberg wrote:
Den mån 15 dec. 2025 kl 23:59 skrev Daniel Sahlberg <
[email protected]>:
After sending, I read through the issue description and it mentions
reproducing with Subversion. So I will make one last try building Serf from
trunk with the usleep() call and see if something gives.
It took a while to find the time to look at this but I've now built Serf
and Subversion from trunk with the added usleep() (plus some randomness
just for fun - the random factor should be between 0.5 and 1.5) and
without/with the SERF-195 patch. I then tried to check out
https://svn.apache.org/repos/private/foundation (which require basic auth).
With a delay between 37.5 ms and 112.5 ms (=average around the 75'000 us in
the bug report) the checkout succeed.
With a delay between 375 ms and 1125 ms (=10 times more then in the bug
report), the checkout fails as follows:
[[[
A foundation/officers/workbench
A foundation/board
X random: 377231.422929 in conn 0x7f23e0b92028
X random: 967579.765638 in conn 0x7f23e0b92028
X random: 590046.259093 in conn 0x7f23e0b92028
X random: 849541.822669 in conn 0x7f23e0b92028
X random: 889138.332808 in conn 0x7f23e0b92028
X random: 866866.873573 in conn 0x7f23e0b92028
X random: 491075.777503 in conn 0x7f23e0b92028
X random: 616534.923083 in conn 0x7f23e0b92028
X random: 785294.915508 in conn 0x7f23e0b92028
X random: 1103729.169573 in conn 0x7f23e0b92028
X random: 638844.156411 in conn 0x7f23e0b92028
X random: 383173.109269 in conn 0x7f23e0d12430
X random: 707753.396282 in conn 0x7f23e0d12430
subversion/svn/checkout-cmd.c:168,
subversion/libsvn_client/checkout.c:318,
subversion/libsvn_client/checkout.c:274,
subversion/libsvn_client/update.c:722,
subversion/libsvn_client/update.c:563,
subversion/libsvn_wc/adm_crawler.c:868,
subversion/libsvn_ra_serf/update.c:2518,
subversion/libsvn_ra_serf/update.c:2508,
subversion/libsvn_ra_serf/update.c:2439,
subversion/libsvn_ra_serf/util.c:966: (apr_err=APR_EOF)
svn: E070014: Error running context: End of file found
]]]
Checking with Wireshark it seems the server is closing the connection on us.
BUT: It isn't the memory corruption issue mentioned and more importantly it
fails exactly the same way both with trunk (no patches, except for the
usleep) and with the SERF-195 branch.
So I'm leaning towards closing SERF-195 as "not reproducible" but I agree
with Brane that the refactoring of linked-list code to dedicated functions
make it easier to review and make sure all cases manage the linked lists
correctly. So we might keep the branch and merge at a later date.
Thoughts?
+1
Let's merge the branch to trunk after the 1.5 release.
-- Brane
