Strange error 500 with svn commit on one simple file

11
votes

We use VisualSVN server here at work and everything works fine, we have over 50 repositories. I tried today to put into a repository a web site but it keeps crashing at one specific single file that i've isolated.

Adding: C:\Work\LAN6505\web\trunk\common_files\includes\fr\debut.inc.php  
Sending content: C:\Work\LAN6505\web\trunk\common_files\includes\fr\debut.inc.php  
Error: Commit failed (details follow):  
Error: Server sent unexpected return value (500 Internal Server Error) in response to  
Error:  PUT request for  
Error:  '/svn/LAN6505/!svn/txr/13-i/web/trunk/common_files/includes/fr/debut.inc.php'  
Completed!:

I simply get a 500 error, no more informations. Anyone know what to do with that? Is there a log file for VisualSvn server that i could look into.

If i copy the file to another repository with similar structure, the problem doesn't occur...

The code of the file can be found : http://pastebin.com/PwTCQSP7

Hope someone can help...

UPDATE

Event Type:       Error
Event Source:   VisualSVN Server 2.5
Event Category:               Apache 
Event ID:             1001
Date:                    1/23/2012
Time:                    9:37:10 AM
User:                    ACTIVIS-991RBEL\Mathieu Dumoulin
Computer:         DELL-PE2900-01
Description:
Could not get next bucket brigade  [500, #0]
[client 192.168.0.64]

UPDATE #2

Soooo, after spending 2.5 days migrating my SVN server on windows to a SVN server on linux, i got the same problem again:

[Fri Feb 24 16:35:21 2012] [error] [client 192.168.0.64] Could not get next bucket brigade (URI: /svn/LAN6505/!svn/wrk/289e3161-cdbf-d44d-9716-c6390289ec92/web/trunk/common_files/includes/fr/debut.inc.php) [500, #0]

[Fri Feb 24 16:36:12 2012] [error] [client 192.168.0.64] Could not get next bucket brigade (URI: /svn/LAN6505/!svn/wrk/554a4a6c-a015-7045-b0c6-072ffe01f854/web/trunk/common_files/includes/fr/debut.inc.php) [500, #0]

[Fri Feb 24 16:48:17 2012] [error] [client 192.168.0.64] Could not get next bucket brigade (URI: /svn/LAN6505/!svn/wrk/15bd0f7e-06b9-b046-8c67-5f9778fab9b5/web/trunk/common_files/includes/fr/debut.inc.php) [500, #0]

8
svntortoisesvnvisualsvn-server
There may be more information in the server logs. Assuming you're running apache, then take a look at Apache's error_log file on the server. – Chris J
I have added information to the question, i've looked around at potential fails regarding this "Could not get next bucket brigade", nothing to do with firewall as internal communications are unafected by firewall. Tried to disable the anti-virus for the repository folders in case something could be interpreted as a virus... Problem is now happening more and more on many other repositories... Is there a way to check the integrity of the SVN repositories? – Mathieu Dumoulin
@MathieuDumoulin - svn verify + (if needed) svn recover. And don't forget about dump before recover – Lazy Badger
I'll fix the issue by "dumping" Visual SVN, just waiting for my boss to order that new server and i'll build it LAMP with linux SVN instead. Never had that before so i suspect it's something to do with an external tool such as a firewall or anti virus... – Mathieu Dumoulin
Oh and btw, this problem has extended to 6/7 other repositories and a dozen file, so it's really something to do with the signature of the file... Thats why i'm pushing this to a non viral solution aware server cause i think it's the anti-virus doing weird things even though there aren't any virus in our code... – Mathieu Dumoulin

8 Answers

4
votes

I have experienced the exactly same problem. It never happens with a local network connection. When I commit to a SVN repository on another side of the planet via VPN it happens often enough.

Turning off Kaspersky Internet Security 2012 helps, but not always.

Moreover, I often do my work and commit from a VirtualBox virtual machine. Sometimes even simple restart of the VM helps.

Another solution is to prevent IP fragmentation. You can check that your packets are fragmented by using the ping command: ping host_name -f

If there is a package fragmentation you can reduce your MTU size. This link provides a good description how to change the MTU size.

Unfortunately, all the above mentioned solutions are not 100% reliable. This error looks like a mystery for me also. I can't understand why SVN is so sensitive to these things.

3
votes

I had a similar problem and I do confirm, that turning off Kaspersky Internet Security 2012 for the time of commit resolves the issue in my case. If somebody is also facing such problem, should check if the antivirus/firewall software doesn't block the svn transmission.

2
votes

This looks like this bug:

It turned out to be in the input filter (having to do with chunked encoding); if the upload ends before expected, the upload fails because the server expects more data, even though the end of stream had been sent.

ok, then the bug is in the input filter.

I was under the (wrong) impression that this bug only appears if content-length is given. But it also appears with chunked encoding if the first chunk is transferred completely and the body is truncated later.

I'd expect two things could help you:

  • An update of VisualSVN to fix this for you; the linked bug is reported to have a fix for apache in r792409

    *) core: Return APR_EOF if request body is shorter than the length announced by the client. PR 33098 [ Stefan Fritsch ]

  • My lack of (recent) experience with VisualSVN makes me doubt whether there might be something going on with the particular file (it may contain offending characters; this being Windows, I believe ascii 26 (^Z) might be interpreted as EOF. See if your file contains any 'funny' characters or you can put it in binary mode (either for the single file, or for the whole server).
1
votes

After all, we found out that simply changing the file and committing works, might still be related to the firewall since it's the only last element in the way. But changing the file's signature works...

really really really strange problem...

1
votes

I think I found a possible source of this error (at least in my case):
This is due to running out of disk space on the disc/partition where your repo is located on.

My case:
Encountered error
Tried to look up if commit succeeded via VisualSVN
Repo was still in state before commit
Coincidentally checked disk space, was zero
Delete some random file to free up memory (ca 10MB)
Commit works now

TL;DR: Free up some memory on the disk your repository is stored on, not enough memeory is likely the culprint of this bug

0
votes

I solved this problem by turning off Kaspersky Internet Security on client PC on commits, but I don't if it will also resolve issue in your case.

0
votes

Anti virus (Kaspersky) program was causing most of the problems in our local office network. Disabling the anti virus program solved the problem (in most cases).

0
votes

I have been suffering this problem over the last few days and have finally managed to fix it.

It looks like by either missing following guides, or my own ignorance I had not done the correct chown on my repository. And It looks like all data was being treated as text, causing end of file characters in binary data to cause the Bucket Brigade error in apache.

Once I had correctly done the chown with the following:

sudo chown -R www-data:www-data /home/svnrepo

My problems have gone away.