Either Bert Huijben or Julian Foad wrote on Wed, Jul 28, 2010 at 15:41:35 +0200: > > > > -----Original Message----- > > From: julianf...@apache.org [mailto:julianf...@apache.org] > > Sent: woensdag 28 juli 2010 15:18 > > To: comm...@subversion.apache.org > > Subject: svn commit: r980046 - > > /subversion/trunk/subversion/libsvn_fs_fs/fs_fs.c > > > > Author: julianfoad > > Date: Wed Jul 28 13:18:28 2010 > > New Revision: 980046 > > > > URL: http://svn.apache.org/viewvc?rev=980046&view=rev > > Log: > > Add assertions in FSFS to trap an internal error that is believed to > > have > > occurred in real life. > > > > See email from me on 2010-06-22, "FSFS error in DAV MERGE - Can't open > > file > > 'db/transactions/props'", <http://svn.haxx.se/dev/archive-2010- > > 06/0327.shtml>. > > I would prefer to see some error here instead of an assertion. As soon as we > know how to trigger this bug, this will most likely be a remotely exploitable > DOS security issue. > > The knowledge that is might be remotely (ab)usable, is the exactly why you > added the test: It can be triggered by remote users. > > > I prefer seeing an error 500 in my logs over an httpd instance on a server > that is crashed because we added an explicit abort() call. >
mod_dav_svn() could call svn_error_set_malfunction_handler() with a handler that logs the error before abort()ing. (@mod_dav_svn folks) Does that sound reasonable? > > Bert > >
