View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0000686 | Subversion for OS/2 & eCS | Bug | public | 2019-03-23 16:58 | 2020-08-24 03:09 |
| Reporter | LewisR | Assigned To | psmedley | ||
| Priority | normal | Severity | major | Reproducibility | always |
| Status | closed | Resolution | unable to reproduce | ||
| Summary | 0000686: svnserve 1.7.21 (all 201903 versions) hangs clients when checking out or updating | ||||
| Description | This is hard to describe. It should be noted that the condition does not seem to occur with the 20181230 build, but it does with 20190309 and the latest 20190323 (so I do not believe this is a regression from the patch applied in 0000685). The symptom is that when updating a repository, the client seems to hang forever. It may be the first repository selected to update, or, if updating by script, as I do, it may be the 5th, 6th, or 30th. The svn.exe build does not seem to matter. Unfortunately, on the server side, with logging enabled in these affected builds, the log file is locked and cannot be read (perhaps a clue to the problem?), and the svnserve.exe instance cannot be killed, requiring a reboot, chkdsk, and invariably, loss of log data around the time the problem presented. | ||||
| Additional Information | To provide proper data for debugging, I'll need to create a testcase on a non-production machine, as it is too disruptive on the live box. For the time being, the workaround seems to be to stick with the 20181230 build of svnserve.exe and the 20190323 builds of the other executables. | ||||
| Tags | No tags attached. | ||||
|
|
The size of the repository is not a factor, and neither is whether or not there are actually updates to fetch. In one of my affected repositories, the repo itself is at r6, and contains 4 directories and 15 small files. The hang is consistent for that repository during daemon starts, however, so when one system fails to update, another also fails to be able to check it out. Further, tests were performed over svn:// across the LAN, so no Apache interference, internet congestion, or routing concerns (same subnet, though different segment). When the troublesome repository update is interrupted (Ctrl-C), the next repository update may or may not run just fine. The daemon process itself is not hung, only access to the affected repository. Lastly, svnadmin verify passes with flying colors on the "troublesome" repository. On the client side, of course, after Ctrl-C, svn cleanup is required before retrying the update. |
|
|
Are you able to check with http://smedley.id.au/tmp/subversion-1.7.21-os2-20190420.zip ? |
|
|
Can we please confirm if this is still an issue with 1.14.x? |
|
|
I have not seen this for some time, either with 1.7.21 or 1.14.0. I don't recall doing anything to address it in terms of configuration, either. If I see it again, I'll open a fresh ticket against 1.14. |
| Date Modified | Username | Field | Change |
|---|---|---|---|
| 2019-03-23 16:58 | LewisR | New Issue | |
| 2019-03-23 17:09 | LewisR | Note Added: 0003281 | |
| 2019-04-20 09:27 | psmedley | Note Added: 0003287 | |
| 2020-08-24 03:04 | psmedley | Assigned To | => psmedley |
| 2020-08-24 03:04 | psmedley | Status | new => feedback |
| 2020-08-24 03:04 | psmedley | Note Added: 0003509 | |
| 2020-08-24 03:09 | LewisR | Status | feedback => resolved |
| 2020-08-24 03:09 | LewisR | Resolution | open => unable to reproduce |
| 2020-08-24 03:09 | LewisR | Note Added: 0003511 | |
| 2020-08-24 03:09 | psmedley | Status | resolved => closed |
