Strange error 500 with svn commit on one simple file

Question

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]

Toyatoyama

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. – Bawdry

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? – Toyatoyama

@MathieuDumoulin - svn verify + (if needed) svn recover. And don't forget about dump before recover – Gare

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... – Toyatoyama

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... – Toyatoyama

Really stupid question - have you checked that you have plenty of file space on the servers? It does sound like either a filesystem running out of space, permissions error or anti-virus being bad rather than an SVN error. – Sortilege

Well if it was a space error, we couldn't have commited 7-8 gigs of downloaded client files in the past day, so no, it's not that... ;) – Toyatoyama

If using VisualSVN, make sure VisualSVN starts as local system rather than network user. – Stalinism

Answer 1

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...

Toyatoyama

Answer 2

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.

Hyonhyoscine

Answer 3

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.

Brashear

Answer 4

This looks like this bug:

• https://issues.apache.org/bugzilla/show_bug.cgi?id=33098

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).

Marquettamarquette

Interresting, could be the solution but i don't know what to do to fix that (r792409) cause i only use the installer and i have the latest installed version, so unless they release a patched version i can't address it. For the invalid character, i'm wondering, wouldn't it do it on all servers? I tried commit the data to another server on a unix machine and it didn't do it... Strange no? – Toyatoyama

And if the tranfer crashed because of some "funny" characters in the URL, wouldn't all files with "funny" characters crash and not only one? I've seen a couple of files passing by with és and ès (people upload files with accents... and our CMS doesn't bother to remove them on upload) and all of them pass, exept for one, every once in a while. – Adnate

@Fredy31: who said anything about URLs? I was talking about file content – Marquettamarquette

@MathieuDumoulin: that's unfortunate. Have you tried the pre-release (visualsvn.com/visualsvn/download/pre-release)? Can't see what upstream that was based on though. Also, wouldn't it do it on all servers - Perhaps not, since there are platform differences on text file handling (depending on which APIs are used with which modes) – Marquettamarquette

Right now, I'd consider the I'll fix the issue by "dumping" Visual SVN approach. +1 – Marquettamarquette

OMG, i spent 2 days migrating from Visual SVN to a brand new Ubuntu based server and the problem persists... – Toyatoyama

Answer 5

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

Berk

Answer 6

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.

Hognut

Answer 7

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).

Stovall

Answer 8

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.

Oculist