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? Cheers, Daniel
