You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by Jon Watte <hp...@mindcontrol.org> on 2002/09/07 21:59:17 UTC
Each access causes need of db_recover?
Hi all,
I wanted to check with the list before posting a bug. I got
the trunk of svn (and all the required upgraded components)
yesterday (Friday) and built/installed apache 2.0.40 with
svn as of revision 3141. I also built and installed php 4.2.3
with all of its baggage (I needed this because of the Apache
upgrade).
Things seemed to work okay. I created a repo and imported
the neon 0.23.3 sources into a "neon" subdirectory. I can
browse this directory locally.
However, when browsing using Internet Explorer 5.5 hitting
the repository directly, I could initially read a few of the
neon html files, but when I got to chap02.html, I got an XML
format error. After this error, pretty much every access to
the neon subdirectory will tell me I need to run db_recover.
Running db_recover will allow me to hit one file, which will
typically give an XML error on the <hr noshade> line as
emitted by the Subversion server browse code, and then I need
to run db_recover again.
I searched the mailing list and the bug db, but couldn't find
any issues similar to this.
I also tried turning off keepalive in httpd.conf, but that
seemed to make the problem, if anything, worse.
The only inkling I've gathered so far is that perhaps svn is
sending data which IE interprets as text/xml, and tries to
apply some xslt on, whereas the text is actually text/html (it
looks very much like HTML to me). Perhaps this parse error
will cause IE to terminate the connection in such a way that
SVN gets a premature shutdown.
Any insights? Ideas for debugging, pointers to FAQs I missed,
patches to apply and marshmallows are all welcome. I'm not
(very) afraid of GDB.
Cheers,
/ h+
--
"Oh, here we go. 'Poor me, my father never gave me
what I wanted for my birthday, boo hoo, my daddy's
the Dark Lord of the Sith.. waahhh wahhh!'"
-- Aussie Beer Ninja
Re: Each access causes need of db_recover?
Posted by Philip Martin <ph...@codematters.co.uk>.
"Jon Watte" <hp...@mindcontrol.org> writes:
> When running apache using -X, I can't get it to fail. This may be an
> Important Clue... Apache actually spawns a thread even if I run it
> with -X, but at least it doesn't seem to fork. So there's two
> possibilities:
I'm not an apache expert, but that doesn't sound right (well obviously
there must be a main thread, but I assume you mean an additional one).
What platform, and how do you know it spwans a thread?
I note you said earlier you were using Apache 2.0.40. Subversion
still recommends CVS HEAD Apache. I don't know if this will help your
server problem, but there is at least one incompatibility between
2.0.40 APR and the svn client.
--
Philip Martin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
RE: Each access causes need of db_recover?
Posted by Jon Watte <hp...@mindcontrol.org>.
> > Any insights? Ideas for debugging, pointers to FAQs I missed,
> > patches to apply and marshmallows are all welcome. I'm not
> > (very) afraid of GDB.
> One thing that causes db_recover to be required is when something
> crashes while holding DB locks. When mod_dav_svn crashes there is
> usually a message in the Apache error log (you may not have noticed
That was my thought, too, but I didn't find any indication of this
in the log (I did check that much at least).
I removed the SetOutputFilter DEFLATE option, and it stayed a little
more stable, but in the end, gave me the "run db_recover" message
again. At that point, local file-based operations hang (as expected).
I'm running this repository on ext3fs. On the off chance that I am
struck by some bad bug, I upgraded everything to August's stable
release, but no joy.
When running apache using -X, I can't get it to fail. This may be an
Important Clue... Apache actually spawns a thread even if I run it
with -X, but at least it doesn't seem to fork. So there's two
possibilities:
1) there's a threading or forking related bug in mod_dav or mod_dav_svn
2) I've made some error when configuring, compiling and installing the
software. As an example: Is there such a thing as a single-threaded-
only glibc? I'm assuming system libraries are always thread safe.
As I said to Daniele Nicolodi off-list: I'm surprised that nobody would
even answer my question, because I'm used to people getting paychecks
during weeks, and doing opensource on week-ends :-)
Thanks for the reply, and I'd be grateful for any more suggestions for
places to poke at. I'm assuming you guys run your servers with a
multi-threaded Apache, so there's probably something wrong on this end
of the wire... but what?
Cheers,
/ h+
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Each access causes need of db_recover?
Posted by Philip Martin <ph...@codematters.co.uk>.
"Jon Watte" <hp...@mindcontrol.org> writes:
> However, when browsing using Internet Explorer 5.5 hitting
> the repository directly, I could initially read a few of the
> neon html files, but when I got to chap02.html, I got an XML
> format error. After this error, pretty much every access to
> the neon subdirectory will tell me I need to run db_recover.
>
> Running db_recover will allow me to hit one file, which will
> typically give an XML error on the <hr noshade> line as
> emitted by the Subversion server browse code, and then I need
> to run db_recover again.
[snip]
> Any insights? Ideas for debugging, pointers to FAQs I missed,
> patches to apply and marshmallows are all welcome. I'm not
> (very) afraid of GDB.
One thing that causes db_recover to be required is when something
crashes while holding DB locks. When mod_dav_svn crashes there is
usually a message in the Apache error log (you may not have noticed
the crash if Apache is multi-process). The easiest way to track it
down is to follow the instructions in the HACKING file and run httpd
with the -X flag. Then when Apache crashes the debugger should catch
it and a stack trace should show you the offending line.
--
Philip Martin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Each access causes need of db_recover?
Posted by Ben Collins-Sussman <su...@collab.net>.
Daniele Nicolodi <da...@grinta.net> writes:
> On Sun, Sep 08, 2002 at 10:59:07AM -0700, Jon Watte wrote:
> >
> >
> > I'm surprised that not one person has been able to give me even
> > one hint about where to start debugging this issue.
>
> Your originary request was on Saturday and today in Sunday ... common
> people don't work on these days so a lot of developper is thinking on
> completely unrelated thinks that subversion, i hope :-)
>
> Wait until Monday.
Indeed, this list is usually very high traffic. But not on weekends.
Have you read the Subversion HACKING file? It specifically describes
how to debug Apache. See IE is able to make mod_dav_svn (and thus
httpd) crash; gdb will show you how and where. If you can reproduce
it, we'd love to see details here.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Each access causes need of db_recover?
Posted by Daniele Nicolodi <da...@grinta.net>.
On Sun, Sep 08, 2002 at 10:59:07AM -0700, Jon Watte wrote:
>
>
> I'm surprised that not one person has been able to give me even
> one hint about where to start debugging this issue.
Your originary request was on Saturday and today in Sunday ... common
people don't work on these days so a lot of developper is thinking on
completely unrelated thinks that subversion, i hope :-)
Wait until Monday.
Ciao
--
Daniele
--- http://www.grinta.net ---
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
RE: Each access causes need of db_recover?
Posted by Jon Watte <sv...@mindcontrol.org>.
I'm surprised that not one person has been able to give me even
one hint about where to start debugging this issue. I'm not
familiar with the internals of apache, nor the internals of
subversion, so I'd rather have someone who is point me at places
where breakpoints may make sense; things to check in config/setup;
etc rather than taking it from the top.
If anyone knows why apache 2.0.40 with subversion 3141 would cause
the database to get corrupted when being browsed with Internet
Explorer 5.5, or how to most easily go about debugging such a
problem, I'm again asking for pointers to where to start.
Cheers,
/ h+
[btw: dev@subversion is now set to plain text mode in Outlook. The
joys of Microsoft software!]
-----Original Message-----
From: Jon Watte [mailto:hplus@mindcontrol.org]
Sent: Saturday, September 07, 2002 2:59 PM
To: dev@subversion.tigris.org
Subject: Each access causes need of db_recover?
Hi all,
I wanted to check with the list before posting a bug. I got
the trunk of svn (and all the required upgraded components)
yesterday (Friday) and built/installed apache 2.0.40 with
svn as of revision 3141. I also built and installed php 4.2.3
with all of its baggage (I needed this because of the Apache
upgrade).
Things seemed to work okay. I created a repo and imported
the neon 0.23.3 sources into a "neon" subdirectory. I can
browse this directory locally.
However, when browsing using Internet Explorer 5.5 hitting
the repository directly, I could initially read a few of the
neon html files, but when I got to chap02.html, I got an XML
format error. After this error, pretty much every access to
the neon subdirectory will tell me I need to run db_recover.
Running db_recover will allow me to hit one file, which will
typically give an XML error on the <hr noshade> line as
emitted by the Subversion server browse code, and then I need
to run db_recover again.
I searched the mailing list and the bug db, but couldn't find
any issues similar to this.
I also tried turning off keepalive in httpd.conf, but that
seemed to make the problem, if anything, worse.
The only inkling I've gathered so far is that perhaps svn is
sending data which IE interprets as text/xml, and tries to
apply some xslt on, whereas the text is actually text/html (it
looks very much like HTML to me). Perhaps this parse error
will cause IE to terminate the connection in such a way that
SVN gets a premature shutdown.
Any insights? Ideas for debugging, pointers to FAQs I missed,
patches to apply and marshmallows are all welcome. I'm not
(very) afraid of GDB.
Cheers,
/ h+
--
"Oh, here we go. 'Poor me, my father never gave me
what I wanted for my birthday, boo hoo, my daddy's
the Dark Lord of the Sith.. waahhh wahhh!'"
-- Aussie Beer Ninja
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org