Bug: Subversion client at 100% cpu if server hangs up due to error

[John Abraham <jo...@theabrahams.ca>]

Hello, I’ve finally figured out the situation in which my subversion client pins the CPU at 100% and never moves beyond it.  And hence I’d like to report a bug.

Sometimes the server hangs up the connection, in my case with this error on the server log:

"Working copy path 'hey it's a file still.txt' does not exist in repository [404, #160013]”

Then the client keeps spinning at 100% forever (15+ hours) and never reports an error to the user.  In particular if a filename recorded on the client doesn’t match a file name on the server.  

Client version 
Client on OSX version is 
svn, version 1.14.1 (r1886195)
   compiled Jul  5 2021, 18:28:42 on x86_64-apple-darwin19.6.0


Our server is a bit old, Ubuntu SVN server 1.9.3. Perhaps newer servers normally hang up more gracefully, with a message to the client? But still, we think this should be classified as a client bug, since the client is the one pinning the end user’s CPU at 100% forever and not saying anything about it. 



BACKGROUND (how we found it and how to reproduce it)

We had an Nginx server in front to the SVN server. And we were doing svn mv on a file with spaces in the filename.  From the client, we did this command

svn mv hey\ it\'s\ a\ file.txt hey\ it\'s\ a\ file\ still.txt 

Which was showing up on the server logs as 

COPY mrsgui-test:/test_space/hey it's a file.txt mrsgui-test:/test_space/hey%20it's%20a%20file%20still.txt

In other words, the server was seeing a different copy command than the client was sending, due to the Nginx controller in front of the svn server deciding to escape some spaces to %20. 

Obviously our test case isn’t subversion’s fault.  BUT we think it’s a bug that the SVN client keeps spinning the CPU at 100% forever if the server decides to hang up for this reason (or perhaps for other reasons?). 

***

Am I supposed to create a ticket for this? Or send it to the dev list?  It took us a long time to figure this out, hoping to save someone else the trouble.

Thanks!

—
John Abraham
john@theabrahams.ca



> On Jun 24, 2021, at 2:20 PM, John Abraham <jo...@theabrahams.ca> wrote:
> 
> I have some internet reliability issues on some clients which seems to cause a big problem with 'svn merge’.  'Svn checkout' seems to be ok, it will either fail (and can be manually restarted) or it will continue.  But 'svn merge’ often just sits there, with no internet traffic, no disk access, no CPU usage. My hypothesis is that this happens after it had some problem connecting to the server, and rather than retrying consistently, or giving up and throwing an error message, it just sits there bored for maybe 45 minutes not knowing what to do.
> 
> What would be a good way to test my theory? Does anyone have another theory?
> 
> It’s a pretty big repo, 26GB, biggest file is 3GB, but the internet traffic monitor today showed it stalling out after only ~10MB of traffic came down…
> 
> Thanks,
> 
> —
> John Abraham
> john@theabrahams.ca <ma...@theabrahams.ca> 
> 
> 
> 
> 
> 
>> On Jun 24, 2021, at 1:31 PM, John Abraham <john@theabrahams.ca <ma...@theabrahams.ca>> wrote:
>> 
> 

Re: Bug: Subversion client at 100% cpu if server hangs up due to error

[Daniel Sahlberg <da...@gmail.com>]

Den mån 26 juli 2021 kl 17:50 skrev John Abraham <jo...@theabrahams.ca>:

> Hello, I’ve finally figured out the situation in which my subversion
> client pins the CPU at 100% and never moves beyond it.  And hence I’d like
> to report a bug.
>
> Sometimes the server hangs up the connection, in my case with this error
> on the server log:
>
> "Working copy path 'hey it's a file still.txt' does not exist in
> repository [404, #160013
> ]”
>
> Then the client keeps spinning at 100% forever (15+ hours) and never
> reports an error to the user.  In particular if a filename recorded on the
> client doesn’t match a file name on the server.
>
> Client version
> Client on OSX version is
> svn, version 1.14.1 (r1886195)
>    compiled Jul  5 2021, 18:28:42 on x86_64-apple-darwin19.6.0
>
>
> Our server is a bit old, Ubuntu SVN server 1.9.3. Perhaps newer servers
> normally hang up more gracefully, with a message to the client? But still,
> we think this should be classified as a client bug, since the client is the
> one pinning the end user’s CPU at 100% forever and not saying anything
> about it.
>
>
>
> BACKGROUND (how we found it and how to reproduce it)
>
> We had an Nginx server in front to the SVN server. And we were doing svn
> mv on a file with spaces in the filename.  From the client, we did this
> command
>
> svn mv hey\ it\'s\ a\ file.txt hey\ it\'s\ a\ file\ still.txt
>
> Which was showing up on the server logs as
>
> COPY mrsgui-test:/test_space/hey it's a file.txt
> mrsgui-test:/test_space/hey%20it's%20a%20file%20still.txt
>
> In other words, the server was seeing a different copy command than the
> client was sending, due to the Nginx controller in front of the svn server
> deciding to escape some spaces to %20.
>
> Obviously our test case isn’t subversion’s fault.  BUT we think it’s a bug
> that the SVN client keeps spinning the CPU at 100% forever if the server
> decides to hang up for this reason (or perhaps for other reasons?).
>
> ***
>
> Am I supposed to create a ticket for this? Or send it to the dev list?  It
> took us a long time to figure this out, hoping to save someone else the
> trouble.
>
> Thanks!
>

Thanks for reporting in such detail!

Is there any chance you can capture the network traffic on your client? Ie
what the server is actually returning.

Kind regards,
Daniel Sahlberg