[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: subversion 1.2.0 - libsvn_repos/reporter.c does not survive gcc 3.4.2 -O2 optimization

From: John Szakmeister <john_at_szakmeister.net>
Date: 2005-06-22 10:50:14 CEST

On Tuesday 21 June 2005 10:43, Kiyo Kelvin Lee wrote:
> John Szakmeister wrote:
> > On Monday 20 June 2005 10:23, Kiyo Kelvin Lee wrote:
> >>I am using FreeBSD 5.4-RELEASE and port subversion-python to build
> >>subversion. And I am also using Apache 2.0.54 (with worker mpm but
> >>prefork has the same problem) and mod_dav_svn.
> >>After I build everything with -O2 using the ports system, svn co
> >> would lead to httpd crashes at the function update_entry() in
> >>libsvn_repos/reporter.c (found by debugging httpd with gdb).
> >>It looked like an code optimization problem, so I went on to
> >> manually recompile reporter.c (with the right flags I believe)
> >> without -O2 and relink libsvn_repos.so. Putting in the new so file,
> >> and svn co works right the way without problem.
> >>Is this a known problem?
> >
> > I've not seen a problem with optimizations, but then I'm using gcc
> 3.3.4.
> > Can you tell me where it's crashing in update_entry()? Maybe the
> problem
> > is a little more serious, and we're just not catching it.
> >
> >>And the problem seems to happen only if I use mod_dav_svn. I tested
> >>with svnserve, the problem does not seem to happen for svnserve.
> >>Also note that I noticed the problem since 1.1.4 but before
> >> reporting the problem I just wanted to check the latest version
> >> 1.2.0 and found the problem is still there.
> >>Regards,
> >>Kiyo
> >
> > -John
> I recompiled libsvn_repos with debug info and here is the log (partial)
> of a gdb session for httpd:
> (gdb) c
> Continuing.
> ### svn co command submitted at this point ###
> Program received signal SIGBUS, Bus error.
> [Switching to Thread 24 (LWP 100124)]
> 0x2876e30f in update_entry (b=Error accessing memory address
> 0xbfa88858: Bad address.
> ) at subversion/libsvn_repos/reporter.c:631
> 631 {
> (gdb) bt
> #0 0x2876e30f in update_entry (b=Error accessing memory address
> 0xbfa88858: Bad address.
> ) at subversion/libsvn_repos/reporter.c:631
> #1 0x2876e21e in delta_dirs (b=0x8205638, s_rev=932, s_path=0x82274b8
> "/", t_path=0x82056a0 "/",
> dir_baton=0x82275e0, e_path=0x287724b2 "", start_empty=136833088,
> pool=0x8206018)
> at subversion/libsvn_repos/reporter.c:857

So I built gcc-3.4.2, built Subversion from then new gcc, and then ran the
testsuite... no failures. Looking at this backtrace, I see two things
that concern me though. The first is that the report baton pointer is
corrupted on the way into update_entry(). How that happened, I'm not
sure. I don't see anything that would have led to that. There are no
stack buffers to overrun, or anything like that. The second problem is
the start_empty parameter to delta_dirs(). That parameter actually comes
from the path_info_t structure, and gets its value as a result of a
boolean expression (i.e., (a == b)). In C99 (and I believe C89, as
well), these expressions evaluate to either 1 or 0. 136833088 is
obviously not 1 or 0. :-)

I don't know if it's possible, but can you try a couple of things. Can
you try a clean installation of Subversion? I mean wipe out any old
libraries that you might have (libsvn_*), etc., and then re-install it.
If you feel brave, can you run the testsuite? In particular, if you can
run subversion/tests/clients/cmdline/davautocheck.sh, then we can see if
you're still getting failures. This is definitely a bizarre problem.

Thanks Kiyo!


To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Wed Jun 22 10:51:38 2005

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.