You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by Kiyo Kelvin Lee <ki...@hotmail.com> on 2005/06/20 14:23:04 UTC
subversion 1.2.0 - libsvn_repos/reporter.c does not survive gcc 3.4.2
-O2 optimization
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?
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
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: subversion 1.2.0 - libsvn_repos/reporter.c does not survive gcc 3.4.2 -O2 optimization
Posted by John Szakmeister <jo...@szakmeister.net>.
On Wednesday 22 June 2005 20:12, Kiyo Kelvin Lee wrote:
[snip]
> I believe my installation is fairly clean as I was installing through
> the port tree of FreeBSD. Just went to the port directory and enter
> make install. There was no manually change applied.
> In addition, pkg_delete or make deinstall seemed working well to delete
> all those files before a new install.
> However, I will try to rebuilt the whole lot and run the testsuite
> later. BTW, just curious, what OS are you using for the test?
> I notice that the problem seemed not happen on Debian. Assuming Debian
> built their binary package with gcc 3.4.x and also with -O2.
> So I still wonder if this is not really a problem of subversion but the
> gcc built from (my?) FreeBSD source.
> I am also thinking once I get the official FreeBSD CD, I may try
> building subversion with that instead. At the moment, my FreeBSD
> installation was built from source myself. There may be something wrong
> with that. But I have also used the same compiler to build my 500+
> packages (including X11 and KDE and also with -O2) installed and
> everything is working fine except subversion. :-(
> Yes, this is really bizarre and that's what gets me interested.
I'm using SuSE 9.2 for my tests. It comes with gcc 3.3.4, which is why I
built gcc 3.4.2. I hope you figure out what the issue is! I wish I
could help more.
-John
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: subversion 1.2.0 - libsvn_repos/reporter.c does not survive gcc
3.4.2 -O2 optimization
Posted by Kiyo Kelvin Lee <ki...@hotmail.com>.
John Szakmeister wrote:
> 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!
>
> -John
I believe my installation is fairly clean as I was installing through
the port tree of FreeBSD. Just went to the port directory and enter make
install. There was no manually change applied.
In addition, pkg_delete or make deinstall seemed working well to delete
all those files before a new install.
However, I will try to rebuilt the whole lot and run the testsuite later.
BTW, just curious, what OS are you using for the test?
I notice that the problem seemed not happen on Debian. Assuming Debian
built their binary package with gcc 3.4.x and also with -O2.
So I still wonder if this is not really a problem of subversion but the
gcc built from (my?) FreeBSD source.
I am also thinking once I get the official FreeBSD CD, I may try
building subversion with that instead. At the moment, my FreeBSD
installation was built from source myself. There may be something wrong
with that. But I have also used the same compiler to build my 500+
packages (including X11 and KDE and also with -O2) installed and
everything is working fine except subversion. :-(
Yes, this is really bizarre and that's what gets me interested.
Regards,
Kiyo
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: subversion 1.2.0 - libsvn_repos/reporter.c does not survive gcc 3.4.2 -O2 optimization
Posted by John Szakmeister <jo...@szakmeister.net>.
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!
-John
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: subversion 1.2.0 - libsvn_repos/reporter.c does not survive gcc
3.4.2 -O2 optimization
Posted by Kiyo Kelvin Lee <ki...@hotmail.com>.
John Szakmeister wrote:
> On Tuesday 21 June 2005 10:43, Kiyo Kelvin Lee wrote:
> [snip]
>
>>The longer full log is attached which mainly added the information
>>about what shared objs are involved.
>>Also attached is b1-release-debug which lists the commands used to
>>build libsvn_repos manually.
>
>
> Thanks, I'll take a closer look at this over the next day or so. Also, if
> you don't mind describing the operation you running, it might help in the
> debugging process.
>
> Thanks again!
>
> -John
What I did is just to check out everything from a repository with
command like:
svn co https://server/svn/svn.root
The repository is not that big (~20M using bdb) and was converted from a
CVS repository using cvs2svn.
Regards,
Kiyo
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: subversion 1.2.0 - libsvn_repos/reporter.c does not survive gcc 3.4.2 -O2 optimization
Posted by John Szakmeister <jo...@szakmeister.net>.
On Tuesday 21 June 2005 10:43, Kiyo Kelvin Lee wrote:
[snip]
> The longer full log is attached which mainly added the information
> about what shared objs are involved.
> Also attached is b1-release-debug which lists the commands used to
> build libsvn_repos manually.
Thanks, I'll take a closer look at this over the next day or so. Also, if
you don't mind describing the operation you running, it might help in the
debugging process.
Thanks again!
-John
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: subversion 1.2.0 - libsvn_repos/reporter.c does not survive gcc
3.4.2 -O2 optimization
Posted by Kiyo Kelvin Lee <ki...@hotmail.com>.
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
#2 0x2876f43f in svn_repos_finish_report (baton=0x8205638, pool=0x8206018)
at subversion/libsvn_repos/reporter.c:913
#3 0x28754d8c in dav_svn__update_report () from
/usr/local/libexec/apache2/mod_dav_svn.so
#4 0x08206018 in ?? ()
#5 0x00000001 in ?? ()
#6 0x00000000 in ?? ()
#7 0x0821a018 in ?? ()
#8 0x0821a018 in ?? ()
#9 0x00000000 in ?? ()
#10 0x00000001 in ?? ()
#11 0x00000001 in ?? ()
#12 0x00000000 in ?? ()
#13 0x082055f8 in ?? ()
#14 0xbfabab80 in ?? ()
#15 0x28752b80 in dav_svn_create_version_resource () from
/usr/local/libexec/apache2/mod_dav_svn.so
Previous frame inner to this frame (corrupt stack?)
(gdb) up
#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
857 SVN_ERR (update_entry (b, s_rev, s_fullpath, s_entry, t_fullpath,
(gdb) l
852 s_entry = s_entries ?
853 apr_hash_get (s_entries, t_entry->name, APR_HASH_KEY_STRING)
: NULL;
854 s_fullpath = s_entry ? svn_path_join (s_path, t_entry->name,
subpool)
855 : NULL;
856
857 SVN_ERR (update_entry (b, s_rev, s_fullpath, s_entry, t_fullpath,
858 t_entry, dir_baton, e_fullpath, NULL,
859 b->recurse, subpool));
860 }
861
(gdb) detach
Detaching from program: /usr/local/sbin/httpd, process 4533
(gdb) q
So obviously, the first arg to update_entry() is somehow corrupted.
The longer full log is attached which mainly added the information about
what shared objs are involved.
Also attached is b1-release-debug which lists the commands used to build
libsvn_repos manually.
Regards,
Kiyo
Re: subversion 1.2.0 - libsvn_repos/reporter.c does not survive gcc 3.4.2 -O2 optimization
Posted by John Szakmeister <jo...@szakmeister.net>.
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
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org