You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by sv...@feb17.org on 2012/03/12 09:19:17 UTC
Segfault in SVN 1.7.4
I started having issues with svn a while back and it took me a while to realize it was segfaulting on the linux side.
I've upgraded to 1.7.4 and the problem remains. I finally ran the operation with apache runnning in GDB and it's a strlen
operation that fails. A lot of vars are optimized out so I didn't get much more information except that it appears
to be trying to report a problem but then dying while reporting.
OS: Linux clowder.feb17.org 2.6.38.8-32.fc15.x86_64 #1 SMP Mon Jun 13 19:49:05 UTC 2011 x86_64 x86_64 x86_64 GNU/Linux
Build details: $ ./configure --prefix=/tools/subersion-1.7.4 --with-apr=/tools/apr-1.3.9/ --with-apr-util=/tools/httpd-2.2.19-src/srclib/apr-util/ --with-apxs=/tools/httpd-2.2.19/bin/apxs --with-neon=/tools/neon-0.29.0 --with-sqlite=/tools/sqlite-3.7.10 --with-sasl=/tools/cyrus-sasl-2.1.25
No berkeley db.
Because I wasn't using this repository too often, I don't know what initiated the unhappiness. It's possibly a file
system change (it's running on secure linux and I suspect I had to move the repository due to disk failure so maybe a
permissions issue). The repository passes checks, can be browsed just fine, but when I commit or create a simple folder
(as in the traceback here), it crashes.
Any help greatly appreciated and if there's something I can do to get better information to you, let me know,
Sincerely,
Darren Platt
Traceback below.
Starting program: /tools/httpd-2.2.19/bin/httpd -X -f /etc/httpd/conf/httpd.conf
[Thread debugging using libthread_db enabled]
Program received signal SIGSEGV, Segmentation fault.
0x0000003be1126d9f in __strlen_sse42 () from /lib64/libc.so.6
Missing separate debuginfos, use: debuginfo-install expat-2.0.1-11.fc15.x86_64 glibc-2.14-2.x86_64 keyutils-libs-1.2-7.fc15.x86_64 krb5-libs-1.9-7.fc15.x86_64 libcom_err-1.41.14-2.fc15.x86_64 libselinux-2.0.99-4.fc15.x86_64 libuuid-2.19.1-1.2.fc15.x86_64 libxml2-devel-2.7.8-6.fc15.x86_64 nss-softokn-freebl-3.12.10-1.fc15.x86_64 openssl-1.0.0d-1.fc15.x86_64 zlib-1.2.5-3.fc15.x86_64
(gdb)
(gdb) where
#0 0x0000003be1126d9f in __strlen_sse42 () from /lib64/libc.so.6
#1 0x00007ffff7ba0e71 in apr_vformatter (flush_func=0x7ffff7bab730 <psprintf_flush>, vbuff=0x7fffffffddd0,
fmt=0x7ffff58be937 "s", ap=0x7fffffffde38) at strings/apr_snprintf.c:974
#2 0x00007ffff7bace16 in apr_pvsprintf (pool=0x83b588, fmt=<optimized out>, ap=<optimized out>)
at memory/unix/apr_pools.c:1142
#3 0x00007ffff7bad0b7 in apr_psprintf (p=<optimized out>, fmt=<optimized out>) at memory/unix/apr_pools.c:2049
#4 0x00007ffff58aafd1 in representation_string (rep=0x82f390, format=<optimized out>,
mutable_rep_truncated=<optimized out>, pool=0x83b588) at subversion/libsvn_fs_fs/fs_fs.c:2449
#5 0x00007ffff58ae971 in svn_fs_fs__write_noderev (pool=0x83b588, include_mergeinfo=1, format=3, noderev=0x82f2a0,
outfile=0x808528) at subversion/libsvn_fs_fs/fs_fs.c:2492
#6 svn_fs_fs__write_noderev (outfile=0x808528, noderev=0x82f2a0, format=3, include_mergeinfo=1, pool=0x83b588)
at subversion/libsvn_fs_fs/fs_fs.c:2469
#7 0x00007ffff58aec33 in svn_fs_fs__put_node_revision (fs=<optimized out>, id=<optimized out>, noderev=0x82f2a0,
fresh_txn_root=1, pool=0x83b588) at subversion/libsvn_fs_fs/fs_fs.c:2559
#8 0x00007ffff58b0e8a in create_new_txn_noderev_from_rev (pool=0x83b588, src=<optimized out>, txn_id=0x82f120 "33-23",
fs=0x826500) at subversion/libsvn_fs_fs/fs_fs.c:4717
#9 svn_fs_fs__create_txn (txn_p=0x7fffffffe0f8, fs=0x826500, rev=33, pool=0x83b588) at subversion/libsvn_fs_fs/fs_fs.c:4892
#10 0x00007ffff58b3c21 in svn_fs_fs__begin_txn (txn_p=0x7fffffffe0f8, fs=0x826500, rev=33, flags=2, pool=0x83b588)
at subversion/libsvn_fs_fs/fs_fs.c:7585
#11 0x00007ffff5cdaf66 in svn_repos_fs_begin_txn_for_commit2 (txn_p=0x7fffffffe0f8, repos=0x802048, rev=33,
revprop_table=0x82ed58, pool=0x83b588) at subversion/libsvn_repos/fs-wrap.c:95
#12 0x00007ffff5f02628 in dav_svn__create_txn (repos=0x82e7e0, ptxn_name=0x7fffffffe138, pool=0x83b588)
at subversion/mod_dav_svn/activity.c:264
#13 0x00007ffff5f07e55 in dav_svn__post_create_txn (resource=0x82e610, request_skel=<optimized out>, output=<optimized out>)
at subversion/mod_dav_svn/posts/create_txn.c:45
#14 0x00007ffff5f13332 in handle_post_request (output=0x83cab0, resource=0x82e610, r=0x83b600)
at subversion/mod_dav_svn/repos.c:4433
#15 dav_svn__method_post (r=0x83b600) at subversion/mod_dav_svn/repos.c:4462
#16 0x00000000004384e8 in ap_run_handler (r=0x83b600) at config.c:158
#17 0x000000000043894e in ap_invoke_handler (r=0x83b600) at config.c:376
#18 0x0000000000445730 in ap_process_request (r=0x83b600) at http_request.c:282
#19 0x0000000000442780 in ap_process_http_connection (c=0x7f25e0) at http_core.c:190
#20 0x000000000043eb08 in ap_run_process_connection (c=0x7f25e0) at connection.c:43
#21 0x0000000000449baf in child_main (child_num_arg=<optimized out>) at prefork.c:667
#22 0x000000000044a290 in make_child (s=0x67c838, slot=0) at prefork.c:712
#23 0x000000000044a9ee in ap_mpm_run (_pconf=<optimized out>, plog=<optimized out>, s=0x67c838) at prefork.c:988
#24 0x0000000000423fb4 in main (argc=4, argv=0x7fffffffe688) at main.c:739
Re: Open mailing lists
Posted by sv...@feb17.org.
Yes again sorry this is probably the wrong place to opine on this topic.
I generally use disposable email addresses but accidentally used a
permanent long term address at one point, otherwise I'd just have
cut off the bleeding there. I don't think it's easy for everyone to
generate lots of disposable addresses.
If there's any way of nuking this page, it would be appreciated
http://mail-archives.apache.org/mod_mbox/subversion-dev/201203.mbox/raw/%3C20120314050552.GM5198@clowder.feb17.org%3E
It doesn't appear to have been replicated yet.
I'm really sorry to disrupt the svn discussion. I've
joined two open source mailing lists and been spammed as a result 100% of the
time, so it's buyer beware. I think it would be wonderful if someone looked at the
list serve infrastructure and made it safer. This feels like telnet circa 1995,
Adieu and thanks for listening,
Darren
> Nearly all open-source projects rely on email communications, and most
> are publicly archived in >1 places.
>
> You could use auto-expiring email addresses (for example,
> address-$((1+$(date +%Y%m%d)))@domain) --- they are still valid but
> pretty useless for spammers.
>
> > Sorry,
> >
> > Darren
> >
> > >
> > > On Mon, Jun 18, 2012 at 3:20 AM, Greg Stein <gs...@gmail.com> wrote:
> > > > Darren,
> > > >
> > > > Over a dozen sites mirror our archives, usually by grabbing our published
> > > > mbox for the list. As a result, we cannot control how they publish the email
> > > > addresses contained within. It is also important for those mboxes to retain
> > > > the email addresses for archival purposes, and so those third-party systems
> > > > can allow proper replies (hopefully, only by humans, but as you've
> > > > discovered... they are not all perfect).
> > > >
> > > > Sorry for any inconvenience, but please don't blame us. We do try to respect
> > > > your privacy in our own web archive system.
> > > >
> > > > Cheers,
> > > > -g
> > > >
> > > > On Jun 18, 2012 5:10 AM, <sv...@feb17.org> wrote:
> > > >>
> > > >> Less than 2 months after using this mailing list I've started getting spam
> > > >> to the custom email address I used to post here. I think it's terrible
> > > >> practice to openly publish email addresses in easily harvestable form. I'll
> > > >> be /dev/nulling this address and unsubscribing. I hope you could reconsider
> > > >> that policy,
> > > >>
> > > >> Darren
> > > >>
> > > >> On Tue, Mar 13, 2012 at 10:05:52PM -0700, daz wrote:
> > > >> > On Tue, Mar 13, 2012 at 07:58:10AM -0500, Hyrum K Wright wrote:
> > > >> > > On Tue, Mar 13, 2012 at 5:45 AM, Philip Martin
> > > >> > > <ph...@wandisco.com> wrote:
> > > >> > > > svn@feb17.org writes:
> > > >> > > >
> > > >> > > >> A little more information on this. I have probably rebuilt svn
> > > >> > > >> about 20 times tonight from scratch, with
> > > >> >
> > > >> > Thanks to everyone who contributed useful clues on this. Using the
> > > >> > current code tree and rebuilding with different versions and combinations of
> > > >> > libraries I narrowed the problem down to the apr version. Either the build
> > > >> > of my earlier apr 1.3.9 or the version itself was the problem. The test
> > > >> > suite was super helpful and the explanation about XFAIL vs FAIL. I have a
> > > >> > build using apr 1.4.6 that passes all the tests it should pass and more
> > > >> > importantly actually works. It might be helpful to print a reminder at
> > > >> > the end of the default make step suggesting running the tests if this is a
> > > >> > common problem. There are a lot of dependencies and some of them seem to be
> > > >> > a bit finicky.
> > > >> >
> > > >> > Thanks!
> > > >> > Darren
> > >
> > >
> > >
> > > --
> > >
> > > uberSVN: Apache Subversion Made Easy
> > > http://www.uberSVN.com/
Re: Open mailing lists
Posted by Daniel Shahaf <d....@daniel.shahaf.name>.
svn@feb17.org wrote on Mon, Jun 18, 2012 at 07:16:01 -0700:
> On Mon, Jun 18, 2012 at 06:14:30AM -0500, Hyrum K Wright wrote:
> > It should also be pointed out that a spammer could easily subscribe
> > directly to the list and get all the address information that way,
> > completely by passing any archives.
> >
> > For completeness, the ASF's public archive policy, which we adhere to,
> > is here: http://www.apache.org/foundation/public-archives.html
> >
> > Best,
> > -Hyrum
>
> At least that's a tiny bit more work for them to sign up for every email
> list serve in the world. Harvesting openly published email addresses is
> just too easy. They would ideally never appear anywhere in the first
> place so they couldn't be mirrored. I understand your constrants but
> I still think this is appalling from an engineering point of view and
> won't participate if it means leaving a please spam me trail behind me.
Nearly all open-source projects rely on email communications, and most
are publicly archived in >1 places.
You could use auto-expiring email addresses (for example,
address-$((1+$(date +%Y%m%d)))@domain) --- they are still valid but
pretty useless for spammers.
> Sorry,
>
> Darren
>
> >
> > On Mon, Jun 18, 2012 at 3:20 AM, Greg Stein <gs...@gmail.com> wrote:
> > > Darren,
> > >
> > > Over a dozen sites mirror our archives, usually by grabbing our published
> > > mbox for the list. As a result, we cannot control how they publish the email
> > > addresses contained within. It is also important for those mboxes to retain
> > > the email addresses for archival purposes, and so those third-party systems
> > > can allow proper replies (hopefully, only by humans, but as you've
> > > discovered... they are not all perfect).
> > >
> > > Sorry for any inconvenience, but please don't blame us. We do try to respect
> > > your privacy in our own web archive system.
> > >
> > > Cheers,
> > > -g
> > >
> > > On Jun 18, 2012 5:10 AM, <sv...@feb17.org> wrote:
> > >>
> > >> Less than 2 months after using this mailing list I've started getting spam
> > >> to the custom email address I used to post here. I think it's terrible
> > >> practice to openly publish email addresses in easily harvestable form. I'll
> > >> be /dev/nulling this address and unsubscribing. I hope you could reconsider
> > >> that policy,
> > >>
> > >> Darren
> > >>
> > >> On Tue, Mar 13, 2012 at 10:05:52PM -0700, daz wrote:
> > >> > On Tue, Mar 13, 2012 at 07:58:10AM -0500, Hyrum K Wright wrote:
> > >> > > On Tue, Mar 13, 2012 at 5:45 AM, Philip Martin
> > >> > > <ph...@wandisco.com> wrote:
> > >> > > > svn@feb17.org writes:
> > >> > > >
> > >> > > >> A little more information on this. I have probably rebuilt svn
> > >> > > >> about 20 times tonight from scratch, with
> > >> >
> > >> > Thanks to everyone who contributed useful clues on this. Using the
> > >> > current code tree and rebuilding with different versions and combinations of
> > >> > libraries I narrowed the problem down to the apr version. Either the build
> > >> > of my earlier apr 1.3.9 or the version itself was the problem. The test
> > >> > suite was super helpful and the explanation about XFAIL vs FAIL. I have a
> > >> > build using apr 1.4.6 that passes all the tests it should pass and more
> > >> > importantly actually works. It might be helpful to print a reminder at
> > >> > the end of the default make step suggesting running the tests if this is a
> > >> > common problem. There are a lot of dependencies and some of them seem to be
> > >> > a bit finicky.
> > >> >
> > >> > Thanks!
> > >> > Darren
> >
> >
> >
> > --
> >
> > uberSVN: Apache Subversion Made Easy
> > http://www.uberSVN.com/
Re: Open mailing lists
Posted by sv...@feb17.org.
On Mon, Jun 18, 2012 at 06:14:30AM -0500, Hyrum K Wright wrote:
> It should also be pointed out that a spammer could easily subscribe
> directly to the list and get all the address information that way,
> completely by passing any archives.
>
> For completeness, the ASF's public archive policy, which we adhere to,
> is here: http://www.apache.org/foundation/public-archives.html
>
> Best,
> -Hyrum
At least that's a tiny bit more work for them to sign up for every email
list serve in the world. Harvesting openly published email addresses is
just too easy. They would ideally never appear anywhere in the first
place so they couldn't be mirrored. I understand your constrants but
I still think this is appalling from an engineering point of view and
won't participate if it means leaving a please spam me trail behind me.
Sorry,
Darren
>
> On Mon, Jun 18, 2012 at 3:20 AM, Greg Stein <gs...@gmail.com> wrote:
> > Darren,
> >
> > Over a dozen sites mirror our archives, usually by grabbing our published
> > mbox for the list. As a result, we cannot control how they publish the email
> > addresses contained within. It is also important for those mboxes to retain
> > the email addresses for archival purposes, and so those third-party systems
> > can allow proper replies (hopefully, only by humans, but as you've
> > discovered... they are not all perfect).
> >
> > Sorry for any inconvenience, but please don't blame us. We do try to respect
> > your privacy in our own web archive system.
> >
> > Cheers,
> > -g
> >
> > On Jun 18, 2012 5:10 AM, <sv...@feb17.org> wrote:
> >>
> >> Less than 2 months after using this mailing list I've started getting spam
> >> to the custom email address I used to post here. I think it's terrible
> >> practice to openly publish email addresses in easily harvestable form. I'll
> >> be /dev/nulling this address and unsubscribing. I hope you could reconsider
> >> that policy,
> >>
> >> Darren
> >>
> >> On Tue, Mar 13, 2012 at 10:05:52PM -0700, daz wrote:
> >> > On Tue, Mar 13, 2012 at 07:58:10AM -0500, Hyrum K Wright wrote:
> >> > > On Tue, Mar 13, 2012 at 5:45 AM, Philip Martin
> >> > > <ph...@wandisco.com> wrote:
> >> > > > svn@feb17.org writes:
> >> > > >
> >> > > >> A little more information on this. I have probably rebuilt svn
> >> > > >> about 20 times tonight from scratch, with
> >> >
> >> > Thanks to everyone who contributed useful clues on this. Using the
> >> > current code tree and rebuilding with different versions and combinations of
> >> > libraries I narrowed the problem down to the apr version. Either the build
> >> > of my earlier apr 1.3.9 or the version itself was the problem. The test
> >> > suite was super helpful and the explanation about XFAIL vs FAIL. I have a
> >> > build using apr 1.4.6 that passes all the tests it should pass and more
> >> > importantly actually works. It might be helpful to print a reminder at
> >> > the end of the default make step suggesting running the tests if this is a
> >> > common problem. There are a lot of dependencies and some of them seem to be
> >> > a bit finicky.
> >> >
> >> > Thanks!
> >> > Darren
>
>
>
> --
>
> uberSVN: Apache Subversion Made Easy
> http://www.uberSVN.com/
Re: Open mailing lists
Posted by Hyrum K Wright <hy...@wandisco.com>.
It should also be pointed out that a spammer could easily subscribe
directly to the list and get all the address information that way,
completely by passing any archives.
For completeness, the ASF's public archive policy, which we adhere to,
is here: http://www.apache.org/foundation/public-archives.html
Best,
-Hyrum
On Mon, Jun 18, 2012 at 3:20 AM, Greg Stein <gs...@gmail.com> wrote:
> Darren,
>
> Over a dozen sites mirror our archives, usually by grabbing our published
> mbox for the list. As a result, we cannot control how they publish the email
> addresses contained within. It is also important for those mboxes to retain
> the email addresses for archival purposes, and so those third-party systems
> can allow proper replies (hopefully, only by humans, but as you've
> discovered... they are not all perfect).
>
> Sorry for any inconvenience, but please don't blame us. We do try to respect
> your privacy in our own web archive system.
>
> Cheers,
> -g
>
> On Jun 18, 2012 5:10 AM, <sv...@feb17.org> wrote:
>>
>> Less than 2 months after using this mailing list I've started getting spam
>> to the custom email address I used to post here. I think it's terrible
>> practice to openly publish email addresses in easily harvestable form. I'll
>> be /dev/nulling this address and unsubscribing. I hope you could reconsider
>> that policy,
>>
>> Darren
>>
>> On Tue, Mar 13, 2012 at 10:05:52PM -0700, daz wrote:
>> > On Tue, Mar 13, 2012 at 07:58:10AM -0500, Hyrum K Wright wrote:
>> > > On Tue, Mar 13, 2012 at 5:45 AM, Philip Martin
>> > > <ph...@wandisco.com> wrote:
>> > > > svn@feb17.org writes:
>> > > >
>> > > >> A little more information on this. I have probably rebuilt svn
>> > > >> about 20 times tonight from scratch, with
>> >
>> > Thanks to everyone who contributed useful clues on this. Using the
>> > current code tree and rebuilding with different versions and combinations of
>> > libraries I narrowed the problem down to the apr version. Either the build
>> > of my earlier apr 1.3.9 or the version itself was the problem. The test
>> > suite was super helpful and the explanation about XFAIL vs FAIL. I have a
>> > build using apr 1.4.6 that passes all the tests it should pass and more
>> > importantly actually works. It might be helpful to print a reminder at
>> > the end of the default make step suggesting running the tests if this is a
>> > common problem. There are a lot of dependencies and some of them seem to be
>> > a bit finicky.
>> >
>> > Thanks!
>> > Darren
--
uberSVN: Apache Subversion Made Easy
http://www.uberSVN.com/
Re: Open mailing lists
Posted by Greg Stein <gs...@gmail.com>.
Darren,
Over a dozen sites mirror our archives, usually by grabbing our published
mbox for the list. As a result, we cannot control how they publish the
email addresses contained within. It is also important for those mboxes to
retain the email addresses for archival purposes, and so those third-party
systems can allow proper replies (hopefully, only by humans, but as you've
discovered... they are not all perfect).
Sorry for any inconvenience, but please don't blame us. We do try to
respect your privacy in our own web archive system.
Cheers,
-g
On Jun 18, 2012 5:10 AM, <sv...@feb17.org> wrote:
> Less than 2 months after using this mailing list I've started getting spam
> to the custom email address I used to post here. I think it's terrible
> practice to openly publish email addresses in easily harvestable form.
> I'll be /dev/nulling this address and unsubscribing. I hope you could
> reconsider that policy,
>
> Darren
>
> On Tue, Mar 13, 2012 at 10:05:52PM -0700, daz wrote:
> > On Tue, Mar 13, 2012 at 07:58:10AM -0500, Hyrum K Wright wrote:
> > > On Tue, Mar 13, 2012 at 5:45 AM, Philip Martin
> > > <ph...@wandisco.com> wrote:
> > > > svn@feb17.org writes:
> > > >
> > > >> A little more information on this. I have probably rebuilt svn
> about 20 times tonight from scratch, with
> >
> > Thanks to everyone who contributed useful clues on this. Using the
> current code tree and rebuilding with different versions and combinations
> of libraries I narrowed the problem down to the apr version. Either the
> build of my earlier apr 1.3.9 or the version itself was the problem. The
> test suite was super helpful and the explanation about XFAIL vs FAIL. I
> have a build using apr 1.4.6 that passes all the tests it should pass and
> more importantly actually works. It might be helpful to print a reminder
> at the end of the default make step suggesting running the tests if this is
> a common problem. There are a lot of dependencies and some of them seem to
> be a bit finicky.
> >
> > Thanks!
> > Darren
>
Open mailing lists
Posted by sv...@feb17.org.
Less than 2 months after using this mailing list I've started getting spam to the custom email address I used to post here. I think it's terrible practice to openly publish email addresses in easily harvestable form. I'll be /dev/nulling this address and unsubscribing. I hope you could reconsider that policy,
Darren
On Tue, Mar 13, 2012 at 10:05:52PM -0700, daz wrote:
> On Tue, Mar 13, 2012 at 07:58:10AM -0500, Hyrum K Wright wrote:
> > On Tue, Mar 13, 2012 at 5:45 AM, Philip Martin
> > <ph...@wandisco.com> wrote:
> > > svn@feb17.org writes:
> > >
> > >> A little more information on this. I have probably rebuilt svn about 20 times tonight from scratch, with
>
> Thanks to everyone who contributed useful clues on this. Using the current code tree and rebuilding with different versions and combinations of libraries I narrowed the problem down to the apr version. Either the build of my earlier apr 1.3.9 or the version itself was the problem. The test suite was super helpful and the explanation about XFAIL vs FAIL. I have a build using apr 1.4.6 that passes all the tests it should pass and more importantly actually works. It might be helpful to print a reminder at the end of the default make step suggesting running the tests if this is a common problem. There are a lot of dependencies and some of them seem to be a bit finicky.
>
> Thanks!
> Darren
svn@feb17.org
Posted by daz <da...@feb17.org>.
On Tue, Mar 13, 2012 at 07:58:10AM -0500, Hyrum K Wright wrote:
> On Tue, Mar 13, 2012 at 5:45 AM, Philip Martin
> <ph...@wandisco.com> wrote:
> > svn@feb17.org writes:
> >
> >> A little more information on this. I have probably rebuilt svn about 20 times tonight from scratch, with
Thanks to everyone who contributed useful clues on this. Using the current code tree and rebuilding with different versions and combinations of libraries I narrowed the problem down to the apr version. Either the build of my earlier apr 1.3.9 or the version itself was the problem. The test suite was super helpful and the explanation about XFAIL vs FAIL. I have a build using apr 1.4.6 that passes all the tests it should pass and more importantly actually works. It might be helpful to print a reminder at the end of the default make step suggesting running the tests if this is a common problem. There are a lot of dependencies and some of them seem to be a bit finicky.
Thanks!
Darren
Re: Segfault in SVN 1.7.4
Posted by Hyrum K Wright <hy...@wandisco.com>.
On Tue, Mar 13, 2012 at 5:45 AM, Philip Martin
<ph...@wandisco.com> wrote:
> svn@feb17.org writes:
>
>> A little more information on this. I have probably rebuilt svn about 20 times tonight from scratch, with
>> latest source from repository, and after upgrading libtools, autoconf, apr etc. It failed the make check
>> tests every time. I finally tried a minimal configure with just the packages needed to get it to build,
>>
>> e.g.
>>
>> ./configure --with-apr=/tools/apr --with-apr-util=/tools/httpd-2.2.19-src/srclib/apr-util/ --with-sqlite=/tools/sqlite-3.7.10
>>
>>
>> versus:
>>
>> ./configure --prefix=/tools/subersion-1.7.4 --with-apr=/tools/apr --with-apr-util=/tools/httpd-2.2.19-src/srclib/apr-util/ --with-apxs=/tools/httpd-2.2.19/bin/apxs --with-neon=/tools/neon-0.29.0 --with-sqlite=/tools/sqlite-3.7.10 --with-sasl=/tools/cyrus-sasl-2.1.25
>
> From tests.log:
>
>> svn_tests: E200004: While reading representation offsets for node-revision '0.0.t0-0':
>> svn_tests: E200004: Could not convert '%ld' into a number
>> FAIL: lt-client-test 3: test svn_client_patch
>
> That looks like an APR problem, apr_snprintf appears to have output a
> literal "%ld" rather than interpreting it as an format specifier. I
> don't know what would cause that, perhaps APR was built with the wrong
> options? Something to do with 32/64 bit support? Or large file
> support?
>
> APR is a dependency of both Subversion and Apache and they need to use
> APRs that are compatible, in almost all cases that means Apache and
> Subversion using the same APR. --with-apxs is the flag that causes
> Subversion to build with Apache so my first guess is that you have
> multiple APRs that are incompatible.
APR doesn't properly parse the %lld format specifier, which is
sometime generated by APR on 64-bit systems, for example OS X:
https://issues.apache.org/bugzilla/show_bug.cgi?id=48476
The corresponding Subversion issue is:
http://subversion.tigris.org/issues/show_bug.cgi?id=3829
While I remember the problem being specific to OS X, and I *think* the
issue was to work around it on that platform, it could come back and
bite other users of 64-bit platforms.
-Hyrum
--
uberSVN: Apache Subversion Made Easy
http://www.uberSVN.com/
Re: Segfault in SVN 1.7.4
Posted by Philip Martin <ph...@wandisco.com>.
svn@feb17.org writes:
> A little more information on this. I have probably rebuilt svn about 20 times tonight from scratch, with
> latest source from repository, and after upgrading libtools, autoconf, apr etc. It failed the make check
> tests every time. I finally tried a minimal configure with just the packages needed to get it to build,
>
> e.g.
>
> ./configure --with-apr=/tools/apr --with-apr-util=/tools/httpd-2.2.19-src/srclib/apr-util/ --with-sqlite=/tools/sqlite-3.7.10
>
>
> versus:
>
> ./configure --prefix=/tools/subersion-1.7.4 --with-apr=/tools/apr --with-apr-util=/tools/httpd-2.2.19-src/srclib/apr-util/ --with-apxs=/tools/httpd-2.2.19/bin/apxs --with-neon=/tools/neon-0.29.0 --with-sqlite=/tools/sqlite-3.7.10 --with-sasl=/tools/cyrus-sasl-2.1.25
>From tests.log:
> svn_tests: E200004: While reading representation offsets for node-revision '0.0.t0-0':
> svn_tests: E200004: Could not convert '%ld' into a number
> FAIL: lt-client-test 3: test svn_client_patch
That looks like an APR problem, apr_snprintf appears to have output a
literal "%ld" rather than interpreting it as an format specifier. I
don't know what would cause that, perhaps APR was built with the wrong
options? Something to do with 32/64 bit support? Or large file
support?
APR is a dependency of both Subversion and Apache and they need to use
APRs that are compatible, in almost all cases that means Apache and
Subversion using the same APR. --with-apxs is the flag that causes
Subversion to build with Apache so my first guess is that you have
multiple APRs that are incompatible.
--
uberSVN: Apache Subversion Made Easy
http://www.uberSVN.com
Re: Segfault in SVN 1.7.4
Posted by Philip Martin <ph...@wandisco.com>.
Ashod Nakashian <as...@yahoo.com> writes:
> XFAIL: update_tests.py 66: update locally modified file to equal versions
> Summary of test results:
> 1594 tests PASSED
> 47 tests SKIPPED
> 42 tests XFAILED (1 WORK-IN-PROGRESS)
That's OK. XFAILs are expected fails, generally things that have not
yet been implemented. FAIL, without the X, is the one that indicates a
problem.
--
uberSVN: Apache Subversion Made Easy
http://www.uberSVN.com
Re: Segfault in SVN 1.7.4
Posted by Ashod Nakashian <as...@yahoo.com>.
>________________________________
> From: Stefan Sperling <st...@elego.de>
>To: svn@feb17.org
>Cc: Philip Martin <ph...@wandisco.com>; dev@subversion.apache.org
>Sent: Tuesday, March 13, 2012 3:44 AM
>Subject: Re: Segfault in SVN 1.7.4
>
>On Mon, Mar 12, 2012 at 10:37:43PM -0700, svn@feb17.org wrote:
>> On Mon, Mar 12, 2012 at 08:30:42PM -0700, svn@feb17.org wrote:
>> > > svn@feb17.org writes:
>> > >
>> > > > to realize it was segfaulting on the linux side. I've upgraded to
>> > > > 1.7.4 and the problem remains. I finally ran the operation with
>> > > > apache runnning in GDB and it's a strlen operation that fails. A lot
>> > > > of vars are optimized out so I didn't get much more information except
>> > > > that it appears to be trying to report a problem but then dying while
>> > > > reporting.
>> > >
>> >
>>
>> A little more information on this. I have probably rebuilt svn about 20 times tonight from scratch, with
>> latest source from repository, and after upgrading libtools, autoconf, apr etc. It failed the make check
>> tests every time. I finally tried a minimal configure with just the packages needed to get it to build,
>>
>> e.g.
>>
>> ./configure --with-apr=/tools/apr --with-apr-util=/tools/httpd-2.2.19-src/srclib/apr-util/ --with-sqlite=/tools/sqlite-3.7.10
>>
>>
>> versus:
>>
>> ./configure --prefix=/tools/subersion-1.7.4 --with-apr=/tools/apr --with-apr-util=/tools/httpd-2.2.19-src/srclib/apr-util/ --with-apxs=/tools/httpd-2.2.19/bin/apxs --with-neon=/tools/neon-0.29.0 --with-sqlite=/tools/sqlite-3.7.10 --with-sasl=/tools/cyrus-sasl-2.1.25
>>
>>
>> and it seems to be passing its tests fine now (it's not very useful built this way, but that narrows down the problem). I'll add back in the extra
>> packages tomorrow till I find which one is breaking things. Thanks for your patience and again if you have any ideas what is causing the problem,
>> I'd be very happy to know. What started as a simple attempt to check in some code has cost a lot of time http://xkcd.com/349/
>>
>> Darren
>
>Why aren't you using pre-compiled binaries to save time?
>See http://subversion.apache.org/packages.html
>
>Given that you're building on 64bit Linux and you get crashes during
>format string parsing this could be a 32bit vs. 64bit library issue.
>I have no better ideas.
>
>
I'm suffering the same fate. I'm also building trunk on 64bit Linux and getting test failures.
./configure --enable-maintainer-mode --without-serf
[...]
At least one test XFAILED, checking /root/subversion/tests.log
XFAIL: lt-diff-diff3-test 13: difference at the start of a 128KB window
XFAIL: lt-fs-test 18: merging commit
[[needs to be written to match new merge() algorithm expectations]]
XFAIL: lt-mergeinfo-test 16: merge of rangelists
XFAIL: lt-op-depth-test 21: test_shadowed_update
XFAIL: lt-op-depth-test 31: move_in_copy
XFAIL: lt-op-depth-test 32: move_in_replace
XFAIL: lt-op-depth-test 36: move_on_move
XFAIL: lt-op-depth-test 37: move_on_move2
XFAIL: lt-op-depth-test 38: move_added
XFAIL: blame_tests.py 15: blame -g handles changes from empty mergeinfo
XFAIL: copy_tests.py 103: copy and move conflicts
XFAIL: diff_tests.py 22: diff a file that has been renamed
XFAIL: diff_tests.py 49: diff URL against working copy with local mods
XFAIL: diff_tests.py 50: diff -r1 of dir with removed-then-readded file
XFAIL: diff_tests.py 61: diff WC-WC shows the correct base rev num
XFAIL: export_tests.py 11: export working copy at base revision
XFAIL: externals_tests.py 37: commit --include-externals --depth=immediates
XFAIL: externals_tests.py 38: external shadows an existing dir
XFAIL: merge_tests.py 49: avoid repeated merges for cyclic merging
XFAIL: merge_tests.py 64: merge target with non inheritable mergeinfo
XFAIL: merge_tests.py 114: don't inherit bogus mergeinfo
XFAIL: merge_tests.py 115: don't inherit bogus working mergeinfo
XFAIL: merge_tests.py 125: svnmucc: merge a replacement
XFAIL: merge_tests.py 126: replacement in merge source not notified correctly
XFAIL: merge_tree_conflict_tests.py 12: tree conflicts 5.1: leaf edit, tree del
XFAIL: merge_tree_conflict_tests.py 13: tree conflicts 5.2: leaf del, tree del
XFAIL: merge_tree_conflict_tests.py 18: tree conflicts 5.2: leaf del (no ci), tree del
XFAIL: merge_tree_conflict_tests.py 23: replace vs. delete tree-conflicts
XFAIL: merge_tree_conflict_tests.py 24: merge replace on local delete fails
XFAIL: resolve_tests.py 2: resolving prop conflicts
XFAIL: revert_tests.py 25: revert a copy with depth=files
XFAIL: revert_tests.py 26: revert a nested add with depth=immediates
XFAIL: special_tests.py 18: merge symlink-add from foreign repos
XFAIL: special_tests.py 22: replace symlinks
XFAIL: special_tests.py 24: cat added symlink
XFAIL: stat_tests.py 36: modified before translation, unmodified after
XFAIL: svnrdump_tests.py 28: dump: subdirectory
XFAIL: svnrdump_tests.py 29: dump: subdirectory with changes on root
XFAIL: switch_tests.py 9: switch a file to a dir and back to the file
XFAIL: tree_conflict_tests.py 14: merge dir: del/rpl/mv onto not-same
XFAIL: update_tests.py 65: update locally moved dir with incoming file move
XFAIL: update_tests.py 66: update locally modified file to equal versions
Summary of test results:
1594 tests PASSED
47 tests SKIPPED
42 tests XFAILED (1 WORK-IN-PROGRESS)
I'm interested in finding the last revision that pass *all* tests on 64bit Linux, if there is such a revision. If I can help fix these failures I'd be happy.
-Ash
Re: Segfault in SVN 1.7.4
Posted by Stefan Sperling <st...@elego.de>.
On Mon, Mar 12, 2012 at 10:37:43PM -0700, svn@feb17.org wrote:
> On Mon, Mar 12, 2012 at 08:30:42PM -0700, svn@feb17.org wrote:
> > > svn@feb17.org writes:
> > >
> > > > to realize it was segfaulting on the linux side. I've upgraded to
> > > > 1.7.4 and the problem remains. I finally ran the operation with
> > > > apache runnning in GDB and it's a strlen operation that fails. A lot
> > > > of vars are optimized out so I didn't get much more information except
> > > > that it appears to be trying to report a problem but then dying while
> > > > reporting.
> > >
> >
>
> A little more information on this. I have probably rebuilt svn about 20 times tonight from scratch, with
> latest source from repository, and after upgrading libtools, autoconf, apr etc. It failed the make check
> tests every time. I finally tried a minimal configure with just the packages needed to get it to build,
>
> e.g.
>
> ./configure --with-apr=/tools/apr --with-apr-util=/tools/httpd-2.2.19-src/srclib/apr-util/ --with-sqlite=/tools/sqlite-3.7.10
>
>
> versus:
>
> ./configure --prefix=/tools/subersion-1.7.4 --with-apr=/tools/apr --with-apr-util=/tools/httpd-2.2.19-src/srclib/apr-util/ --with-apxs=/tools/httpd-2.2.19/bin/apxs --with-neon=/tools/neon-0.29.0 --with-sqlite=/tools/sqlite-3.7.10 --with-sasl=/tools/cyrus-sasl-2.1.25
>
>
> and it seems to be passing its tests fine now (it's not very useful built this way, but that narrows down the problem). I'll add back in the extra
> packages tomorrow till I find which one is breaking things. Thanks for your patience and again if you have any ideas what is causing the problem,
> I'd be very happy to know. What started as a simple attempt to check in some code has cost a lot of time http://xkcd.com/349/
>
> Darren
Why aren't you using pre-compiled binaries to save time?
See http://subversion.apache.org/packages.html
Given that you're building on 64bit Linux and you get crashes during
format string parsing this could be a 32bit vs. 64bit library issue.
I have no better ideas.
Re: Segfault in SVN 1.7.4
Posted by sv...@feb17.org.
On Mon, Mar 12, 2012 at 08:30:42PM -0700, svn@feb17.org wrote:
> > svn@feb17.org writes:
> >
> > > to realize it was segfaulting on the linux side. I've upgraded to
> > > 1.7.4 and the problem remains. I finally ran the operation with
> > > apache runnning in GDB and it's a strlen operation that fails. A lot
> > > of vars are optimized out so I didn't get much more information except
> > > that it appears to be trying to report a problem but then dying while
> > > reporting.
> >
>
A little more information on this. I have probably rebuilt svn about 20 times tonight from scratch, with
latest source from repository, and after upgrading libtools, autoconf, apr etc. It failed the make check
tests every time. I finally tried a minimal configure with just the packages needed to get it to build,
e.g.
./configure --with-apr=/tools/apr --with-apr-util=/tools/httpd-2.2.19-src/srclib/apr-util/ --with-sqlite=/tools/sqlite-3.7.10
versus:
./configure --prefix=/tools/subersion-1.7.4 --with-apr=/tools/apr --with-apr-util=/tools/httpd-2.2.19-src/srclib/apr-util/ --with-apxs=/tools/httpd-2.2.19/bin/apxs --with-neon=/tools/neon-0.29.0 --with-sqlite=/tools/sqlite-3.7.10 --with-sasl=/tools/cyrus-sasl-2.1.25
and it seems to be passing its tests fine now (it's not very useful built this way, but that narrows down the problem). I'll add back in the extra
packages tomorrow till I find which one is breaking things. Thanks for your patience and again if you have any ideas what is causing the problem,
I'd be very happy to know. What started as a simple attempt to check in some code has cost a lot of time http://xkcd.com/349/
Darren
Re: Segfault in SVN 1.7.4
Posted by sv...@feb17.org.
> svn@feb17.org writes:
>
> > to realize it was segfaulting on the linux side. I've upgraded to
> > 1.7.4 and the problem remains. I finally ran the operation with
> > apache runnning in GDB and it's a strlen operation that fails. A lot
> > of vars are optimized out so I didn't get much more information except
> > that it appears to be trying to report a problem but then dying while
> > reporting.
>
Answers to questions:
rep[0] is: {md5_checksum = 0x828c20, sha1_checksum = 0x0, revision = 33, offset = 750127, size = 43, expanded_size = 43, txn_id = 0x0, uniquifier = 0x0}
> Does the Subversion testsuite PASS?
Good suggestion, no it appears to fail a series of tests. There seems to be some problem
with format strings, not getting their actual values inserted. Full test log attached,
does that suggest any particular form of misadventure?
Darren
e.g.
EXPECTED:
--- foo2
+++ bar2
@@ -1,3 +0,0 @@
-Aa
-Bb
-Cc
ACTUAL:
--- foo2
+++ bar2
@@ -%ld,%ld +%ld,%ld (null)
-Aa
-Bb
-Cc
[root@clowder subversion-1.7.4-src]# make check
Running tests in auth-test [1/84].............................success
Running tests in cache-test [2/84]............................success
Running tests in checksum-test [3/84].........................success
Running tests in client-test [4/84]...........................FAILURE
Running tests in compat-test [5/84]...........................success
Running tests in config-test [6/84]...........................success
Running tests in db-test [7/84]...............................FAILURE
Running tests in diff-diff3-test [8/84]...FAILURE
Running tests in dirent_uri-test [9/84].......................success
Running tests in entries-compat-test [10/84]..................success
Running tests in error-test [11/84]...........................success
Running tests in fs-pack-test [12/84].........................FAILURE
Running tests in fs-test [13/84]..............................FAILURE
Running tests in hashdump-test [14/84]........................success
Running tests in locks-test [15/84]...........................FAILURE
Running tests in mergeinfo-test [16/84].......................success
Running tests in op-depth-test [17/84]........................FAILURE
Running tests in opt-test [18/84].............................success
Running tests in parse-diff-test [19/84]......................success
Running tests in path-test [20/84]............................success
Running tests in pristine-store-test [21/84]..................success
Running tests in ra-local-test [22/84]........................success
Running tests in random-test [23/84]..........................success
Running tests in repos-test [24/84]...........................FAILURE
Running tests in revision-test [25/84]........................success
Running tests in skel-test [26/84]............................success
Running tests in stream-test [27/84]..........................success
Running tests in string-test [28/84]..........................success
Running tests in subst_translate-test [29/84].................success
Running tests in target-test [30/84]..........................success
Running tests in time-test [31/84]............................success
Running tests in translate-test [32/84].......................success
Running tests in tree-conflict-data-test [33/84]..............success
Running tests in utf-test [34/84].............................success
Running tests in window-test [35/84]..........................success
Running tests in authz_tests.py [36/84]make: *** [check] Error 1
> > Program received signal SIGSEGV, Segmentation fault.
> > 0x0000003be1126d9f in __strlen_sse42 () from /lib64/libc.so.6
> > Missing separate debuginfos, use: debuginfo-install expat-2.0.1-11.fc15.x86_64 glibc-2.14-2.x86_64 keyutils-libs-1.2-7.fc15.x86_64 krb5-libs-1.9-7.fc15.x86_64 libcom_err-1.41.14-2.fc15.x86_64 libselinux-2.0.99-4.fc15.x86_64 libuuid-2.19.1-1.2.fc15.x86_64 libxml2-devel-2.7.8-6.fc15.x86_64 nss-softokn-freebl-3.12.10-1.fc15.x86_64 openssl-1.0.0d-1.fc15.x86_64 zlib-1.2.5-3.fc15.x86_64
> > (gdb)
> > (gdb) where
> > #0 0x0000003be1126d9f in __strlen_sse42 () from /lib64/libc.so.6
> > #1 0x00007ffff7ba0e71 in apr_vformatter (flush_func=0x7ffff7bab730 <psprintf_flush>, vbuff=0x7fffffffddd0,
> > fmt=0x7ffff58be937 "s", ap=0x7fffffffde38) at strings/apr_snprintf.c:974
> > #2 0x00007ffff7bace16 in apr_pvsprintf (pool=0x83b588, fmt=<optimized out>, ap=<optimized out>)
> > at memory/unix/apr_pools.c:1142
> > #3 0x00007ffff7bad0b7 in apr_psprintf (p=<optimized out>, fmt=<optimized out>) at memory/unix/apr_pools.c:2049
> > #4 0x00007ffff58aafd1 in representation_string (rep=0x82f390, format=<optimized out>,
>
> In gdb print rep[0].
{md5_checksum = 0x828c20, sha1_checksum = 0x0, revision = 33, offset = 750127, size = 43, expanded_size = 43, txn_id = 0x0, uniquifier = 0x0}
>
> > mutable_rep_truncated=<optimized out>, pool=0x83b588) at subversion/libsvn_fs_fs/fs_fs.c:2449
> > #5 0x00007ffff58ae971 in svn_fs_fs__write_noderev (pool=0x83b588, include_mergeinfo=1, format=3, noderev=0x82f2a0,
> > outfile=0x808528) at subversion/libsvn_fs_fs/fs_fs.c:2492
> > #6 svn_fs_fs__write_noderev (outfile=0x808528, noderev=0x82f2a0, format=3, include_mergeinfo=1, pool=0x83b588)
> > at subversion/libsvn_fs_fs/fs_fs.c:2469
> > #7 0x00007ffff58aec33 in svn_fs_fs__put_node_revision (fs=<optimized out>, id=<optimized out>, noderev=0x82f2a0,
> > fresh_txn_root=1, pool=0x83b588) at subversion/libsvn_fs_fs/fs_fs.c:2559
> > #8 0x00007ffff58b0e8a in create_new_txn_noderev_from_rev (pool=0x83b588, src=<optimized out>, txn_id=0x82f120 "33-23",
> > fs=0x826500) at subversion/libsvn_fs_fs/fs_fs.c:4717
> > #9 svn_fs_fs__create_txn (txn_p=0x7fffffffe0f8, fs=0x826500, rev=33, pool=0x83b588) at subversion/libsvn_fs_fs/fs_fs.c:4892
> > #10 0x00007ffff58b3c21 in svn_fs_fs__begin_txn (txn_p=0x7fffffffe0f8, fs=0x826500, rev=33, flags=2, pool=0x83b588)
> > at subversion/libsvn_fs_fs/fs_fs.c:7585
> > #11 0x00007ffff5cdaf66 in svn_repos_fs_begin_txn_for_commit2 (txn_p=0x7fffffffe0f8, repos=0x802048, rev=33,
> > revprop_table=0x82ed58, pool=0x83b588) at subversion/libsvn_repos/fs-wrap.c:95
> > #12 0x00007ffff5f02628 in dav_svn__create_txn (repos=0x82e7e0, ptxn_name=0x7fffffffe138, pool=0x83b588)
> > at subversion/mod_dav_svn/activity.c:264
> > #13 0x00007ffff5f07e55 in dav_svn__post_create_txn (resource=0x82e610, request_skel=<optimized out>, output=<optimized out>)
> > at subversion/mod_dav_svn/posts/create_txn.c:45
> > #14 0x00007ffff5f13332 in handle_post_request (output=0x83cab0, resource=0x82e610, r=0x83b600)
> > at subversion/mod_dav_svn/repos.c:4433
> > #15 dav_svn__method_post (r=0x83b600) at subversion/mod_dav_svn/repos.c:4462
> > #16 0x00000000004384e8 in ap_run_handler (r=0x83b600) at config.c:158
> > #17 0x000000000043894e in ap_invoke_handler (r=0x83b600) at config.c:376
> > #18 0x0000000000445730 in ap_process_request (r=0x83b600) at http_request.c:282
> > #19 0x0000000000442780 in ap_process_http_connection (c=0x7f25e0) at http_core.c:190
> > #20 0x000000000043eb08 in ap_run_process_connection (c=0x7f25e0) at connection.c:43
> > #21 0x0000000000449baf in child_main (child_num_arg=<optimized out>) at prefork.c:667
> > #22 0x000000000044a290 in make_child (s=0x67c838, slot=0) at prefork.c:712
> > #23 0x000000000044a9ee in ap_mpm_run (_pconf=<optimized out>, plog=<optimized out>, s=0x67c838) at prefork.c:988
> > #24 0x0000000000423fb4 in main (argc=4, argv=0x7fffffffe688) at main.c:739
> >
>
> --
> uberSVN: Apache Subversion Made Easy
> http://www.uberSVN.com
Re: Segfault in SVN 1.7.4
Posted by Philip Martin <ph...@wandisco.com>.
svn@feb17.org writes:
> I started having issues with svn a while back and it took me a while
> to realize it was segfaulting on the linux side. I've upgraded to
> 1.7.4 and the problem remains. I finally ran the operation with
> apache runnning in GDB and it's a strlen operation that fails. A lot
> of vars are optimized out so I didn't get much more information except
> that it appears to be trying to report a problem but then dying while
> reporting.
Building without optimisation may make it easier to debug.
>
> OS: Linux clowder.feb17.org 2.6.38.8-32.fc15.x86_64 #1 SMP Mon Jun 13 19:49:05 UTC 2011 x86_64 x86_64 x86_64 GNU/Linux
>
> Build details: $ ./configure --prefix=/tools/subersion-1.7.4 --with-apr=/tools/apr-1.3.9/ --with-apr-util=/tools/httpd-2.2.19-src/srclib/apr-util/ --with-apxs=/tools/httpd-2.2.19/bin/apxs --with-neon=/tools/neon-0.29.0 --with-sqlite=/tools/sqlite-3.7.10 --with-sasl=/tools/cyrus-sasl-2.1.25
>
> No berkeley db.
Does the Subversion testsuite PASS?
>
> Because I wasn't using this repository too often, I don't know what
> initiated the unhappiness. It's possibly a file system change (it's
> running on secure linux and I suspect I had to move the repository due
> to disk failure so maybe a permissions issue). The repository passes
> checks, can be browsed just fine, but when I commit or create a simple
> folder (as in the traceback here), it crashes.
>
> Any help greatly appreciated and if there's something I can do to get
> better information to you, let me know,
>
> Sincerely,
>
> Darren Platt
>
>
> Traceback below.
>
>
> Starting program: /tools/httpd-2.2.19/bin/httpd -X -f /etc/httpd/conf/httpd.conf
> [Thread debugging using libthread_db enabled]
>
> Program received signal SIGSEGV, Segmentation fault.
> 0x0000003be1126d9f in __strlen_sse42 () from /lib64/libc.so.6
> Missing separate debuginfos, use: debuginfo-install expat-2.0.1-11.fc15.x86_64 glibc-2.14-2.x86_64 keyutils-libs-1.2-7.fc15.x86_64 krb5-libs-1.9-7.fc15.x86_64 libcom_err-1.41.14-2.fc15.x86_64 libselinux-2.0.99-4.fc15.x86_64 libuuid-2.19.1-1.2.fc15.x86_64 libxml2-devel-2.7.8-6.fc15.x86_64 nss-softokn-freebl-3.12.10-1.fc15.x86_64 openssl-1.0.0d-1.fc15.x86_64 zlib-1.2.5-3.fc15.x86_64
> (gdb)
> (gdb) where
> #0 0x0000003be1126d9f in __strlen_sse42 () from /lib64/libc.so.6
> #1 0x00007ffff7ba0e71 in apr_vformatter (flush_func=0x7ffff7bab730 <psprintf_flush>, vbuff=0x7fffffffddd0,
> fmt=0x7ffff58be937 "s", ap=0x7fffffffde38) at strings/apr_snprintf.c:974
> #2 0x00007ffff7bace16 in apr_pvsprintf (pool=0x83b588, fmt=<optimized out>, ap=<optimized out>)
> at memory/unix/apr_pools.c:1142
> #3 0x00007ffff7bad0b7 in apr_psprintf (p=<optimized out>, fmt=<optimized out>) at memory/unix/apr_pools.c:2049
> #4 0x00007ffff58aafd1 in representation_string (rep=0x82f390, format=<optimized out>,
In gdb print rep[0].
> mutable_rep_truncated=<optimized out>, pool=0x83b588) at subversion/libsvn_fs_fs/fs_fs.c:2449
> #5 0x00007ffff58ae971 in svn_fs_fs__write_noderev (pool=0x83b588, include_mergeinfo=1, format=3, noderev=0x82f2a0,
> outfile=0x808528) at subversion/libsvn_fs_fs/fs_fs.c:2492
> #6 svn_fs_fs__write_noderev (outfile=0x808528, noderev=0x82f2a0, format=3, include_mergeinfo=1, pool=0x83b588)
> at subversion/libsvn_fs_fs/fs_fs.c:2469
> #7 0x00007ffff58aec33 in svn_fs_fs__put_node_revision (fs=<optimized out>, id=<optimized out>, noderev=0x82f2a0,
> fresh_txn_root=1, pool=0x83b588) at subversion/libsvn_fs_fs/fs_fs.c:2559
> #8 0x00007ffff58b0e8a in create_new_txn_noderev_from_rev (pool=0x83b588, src=<optimized out>, txn_id=0x82f120 "33-23",
> fs=0x826500) at subversion/libsvn_fs_fs/fs_fs.c:4717
> #9 svn_fs_fs__create_txn (txn_p=0x7fffffffe0f8, fs=0x826500, rev=33, pool=0x83b588) at subversion/libsvn_fs_fs/fs_fs.c:4892
> #10 0x00007ffff58b3c21 in svn_fs_fs__begin_txn (txn_p=0x7fffffffe0f8, fs=0x826500, rev=33, flags=2, pool=0x83b588)
> at subversion/libsvn_fs_fs/fs_fs.c:7585
> #11 0x00007ffff5cdaf66 in svn_repos_fs_begin_txn_for_commit2 (txn_p=0x7fffffffe0f8, repos=0x802048, rev=33,
> revprop_table=0x82ed58, pool=0x83b588) at subversion/libsvn_repos/fs-wrap.c:95
> #12 0x00007ffff5f02628 in dav_svn__create_txn (repos=0x82e7e0, ptxn_name=0x7fffffffe138, pool=0x83b588)
> at subversion/mod_dav_svn/activity.c:264
> #13 0x00007ffff5f07e55 in dav_svn__post_create_txn (resource=0x82e610, request_skel=<optimized out>, output=<optimized out>)
> at subversion/mod_dav_svn/posts/create_txn.c:45
> #14 0x00007ffff5f13332 in handle_post_request (output=0x83cab0, resource=0x82e610, r=0x83b600)
> at subversion/mod_dav_svn/repos.c:4433
> #15 dav_svn__method_post (r=0x83b600) at subversion/mod_dav_svn/repos.c:4462
> #16 0x00000000004384e8 in ap_run_handler (r=0x83b600) at config.c:158
> #17 0x000000000043894e in ap_invoke_handler (r=0x83b600) at config.c:376
> #18 0x0000000000445730 in ap_process_request (r=0x83b600) at http_request.c:282
> #19 0x0000000000442780 in ap_process_http_connection (c=0x7f25e0) at http_core.c:190
> #20 0x000000000043eb08 in ap_run_process_connection (c=0x7f25e0) at connection.c:43
> #21 0x0000000000449baf in child_main (child_num_arg=<optimized out>) at prefork.c:667
> #22 0x000000000044a290 in make_child (s=0x67c838, slot=0) at prefork.c:712
> #23 0x000000000044a9ee in ap_mpm_run (_pconf=<optimized out>, plog=<optimized out>, s=0x67c838) at prefork.c:988
> #24 0x0000000000423fb4 in main (argc=4, argv=0x7fffffffe688) at main.c:739
>
--
uberSVN: Apache Subversion Made Easy
http://www.uberSVN.com