You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by "Hyrum K. Wright" <hy...@hyrumwright.org> on 2009/07/21 00:10:24 UTC
Segfault in 1.6.x (with serf, methinks)
A recent segfault encountered while running 1.6.x:
(gdb) r up
Starting program: /home/hwright/dev/svn-1.6.x/subversion/svn/svn up
[Thread debugging using libthread_db enabled]
[New Thread 0x7ff9ee041760 (LWP 10097)]
Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0x7ff9ee041760 (LWP 10097)]
apr_allocator_alloc (allocator=0x0, size=16320) at memory/unix/
apr_pools.c:219
219 if (index <= allocator->max_index) {
(gdb) backtrace
#0 apr_allocator_alloc (allocator=0x0, size=16320) at memory/unix/
apr_pools.c:219
#1 0x00007ff9edc42a8c in serf_bucket_mem_alloc (allocator=0xfbd350,
size=16320)
at buckets/allocator.c:197
#2 0x00007ff9edc43f37 in serf_bucket_ssl_create (ssl_ctx=0x138,
allocator=0xf345d0, type=0x7ff9ede47ba0) at buckets/ssl_buckets.c:
911
#3 0x00007ff9edc442b0 in serf_bucket_ssl_decrypt_create
(stream=0xe31998,
ssl_ctx=0x0, allocator=0xf345d0) at buckets/ssl_buckets.c:1048
#4 0x000000000050f4f8 in svn_ra_serf__conn_setup (sock=0xf64130,
baton=0xfb58c0,
pool=0xded4b0) at subversion/libsvn_ra_serf/util.c:238
#5 0x00007ff9edc405e6 in serf_event_trigger (s=<value optimized out>,
serf_baton=0xdedd70, desc=<value optimized out>) at context.c:673
#6 0x00007ff9edc40953 in serf_context_run (ctx=0xfc26e0,
duration=<value optimized out>, pool=<value optimized out>) at
context.c:1143
#7 0x000000000050fc0d in svn_ra_serf__context_run_wait
(done=0x7ffff6065c28,
sess=0xf80290, pool=0xdeccf0) at subversion/libsvn_ra_serf/util.c:
534
#8 0x0000000000506fa5 in exchange_capabilities (serf_sess=0xf80290,
pool=0xdeccf0)
at subversion/libsvn_ra_serf/serf.c:184
#9 0x0000000000507d93 in svn_ra_serf__open (session=0xe27aa0,
repos_URL=0xdf7e00 "https://svn.collab.net/repos/svn/trunk",
callbacks=0xfc1e80, callback_baton=0xf95770, config=0xde4380,
pool=0xdeccf0)
at subversion/libsvn_ra_serf/serf.c:581
#10 0x000000000049c0c0 in svn_ra_open3 (session_p=0x7ffff6066110,
repos_URL=0xdf7e00 "https://svn.collab.net/repos/svn/trunk",
uuid=0xdf30c0 "612f8ebc-c883-4be0-9ee0-a4e9ef946e3a",
callbacks=0xfc1e80,
callback_baton=0xf95770, config=0xde4380, pool=0xdeccf0)
at subversion/libsvn_ra/ra_loader.c:480
#11 0x0000000000455c93 in svn_client__open_ra_session_internal (
ra_session=0x7ffff6066110,
base_url=0xdf7e00 "https://svn.collab.net/repos/svn/trunk",
base_dir=0xdedb40 "", base_access=0xdedaf0, commit_items=0x0,
use_admin=1,
read_only_wc=1, ctx=0xde42d0, pool=0xdeccf0)
at subversion/libsvn_client/ra.c:295
#12 0x000000000045c3df in svn_client__update_internal
(result_rev=0x7ffff6066240,
path=0xdecbd0 "", revision=0x7ffff6066388, depth=svn_depth_unknown,
depth_is_sticky=0, ignore_externals=0, allow_unver_obstructions=0,
timestamp_sleep=0x7ffff6066260, send_copyfrom_args=1, ctx=0xde42d0,
pool=0xdeccf0) at subversion/libsvn_client/update.c:207
#13 0x000000000045ca87 in svn_client_update3 (result_revs=0x0,
paths=0xdecb70,
revision=0x7ffff6066388, depth=svn_depth_unknown,
depth_is_sticky=0,
ignore_externals=0, allow_unver_obstructions=0, ctx=0xde42d0,
pool=0xde2bb0)
at subversion/libsvn_client/update.c:346
#14 0x000000000041ccff in svn_cl__update (os=0xde3320,
baton=0x7ffff6066580,
pool=0xde2bb0) at subversion/svn/update-cmd.c:84
#15 0x00000000004144e9 in main (argc=2, argv=0x7ffff6066788)
at subversion/svn/main.c:2123
All I did was attempt to run 'svn up' on a trunk working copy using a
recent build of the 1.6.x branch. I can do more forensics if anybody
needs it.
-Hyrum
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=462&dsMessageId=2372772
Re: Segfault in 1.6.x (with serf, methinks)
Posted by "Hyrum K. Wright" <hy...@hyrumwright.org>.
On Sep 21, 2009, at 3:20 PM, Lieven Govaerts wrote:
> On Tue, Jul 21, 2009 at 2:10 AM, Hyrum K. Wright <hyrum@hyrumwright.org
> > wrote:
>> A recent segfault encountered while running 1.6.x:
>>
>> (gdb) r up
>> Starting program: /home/hwright/dev/svn-1.6.x/subversion/svn/svn up
>> [Thread debugging using libthread_db enabled]
>> [New Thread 0x7ff9ee041760 (LWP 10097)]
>>
>> Program received signal SIGSEGV, Segmentation fault.
>> [Switching to Thread 0x7ff9ee041760 (LWP 10097)]
>> apr_allocator_alloc (allocator=0x0, size=16320) at memory/unix/
>> apr_pools.c:219
>> 219 if (index <= allocator->max_index) {
>> (gdb) backtrace
>> #0 apr_allocator_alloc (allocator=0x0, size=16320) at memory/unix/
>> apr_pools.c:219
>> #1 0x00007ff9edc42a8c in serf_bucket_mem_alloc (allocator=0xfbd350,
>> size=16320)
>> at buckets/allocator.c:197
>> #2 0x00007ff9edc43f37 in serf_bucket_ssl_create (ssl_ctx=0x138,
>> allocator=0xf345d0, type=0x7ff9ede47ba0) at buckets/
>> ssl_buckets.c:
>> 911
>
> Hm, this is weird. The code at this line (ssl_buckets.c:911 creates
> the allocator and then directly uses it):
>
> <code extract>
> apr_pool_create(&pool, NULL);
> allocator = serf_bucket_allocator_create(pool, NULL, NULL);
>
> ssl_ctx = serf_bucket_mem_alloc(allocator, sizeof(*ssl_ctx));
> </code extract>
>
> The allocator used in serf_bucket_mem_alloc is the one from the new
> pool.
>
> I've found a thread on dev@perl.apache.org with a similar stacktrace,
> which points to pool debugging in apr/apr-util as the rootcause of
> this issue. Possible?
Dunno. I haven't hit the issue in a while.
-Hyrum
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=462&dsMessageId=2398880
Re: Segfault in 1.6.x (with serf, methinks)
Posted by Lieven Govaerts <sv...@mobsol.be>.
On Tue, Jul 21, 2009 at 2:10 AM, Hyrum K. Wright <hy...@hyrumwright.org> wrote:
> A recent segfault encountered while running 1.6.x:
>
> (gdb) r up
> Starting program: /home/hwright/dev/svn-1.6.x/subversion/svn/svn up
> [Thread debugging using libthread_db enabled]
> [New Thread 0x7ff9ee041760 (LWP 10097)]
>
> Program received signal SIGSEGV, Segmentation fault.
> [Switching to Thread 0x7ff9ee041760 (LWP 10097)]
> apr_allocator_alloc (allocator=0x0, size=16320) at memory/unix/
> apr_pools.c:219
> 219 if (index <= allocator->max_index) {
> (gdb) backtrace
> #0 apr_allocator_alloc (allocator=0x0, size=16320) at memory/unix/
> apr_pools.c:219
> #1 0x00007ff9edc42a8c in serf_bucket_mem_alloc (allocator=0xfbd350,
> size=16320)
> at buckets/allocator.c:197
> #2 0x00007ff9edc43f37 in serf_bucket_ssl_create (ssl_ctx=0x138,
> allocator=0xf345d0, type=0x7ff9ede47ba0) at buckets/ssl_buckets.c:
> 911
Hm, this is weird. The code at this line (ssl_buckets.c:911 creates
the allocator and then directly uses it):
<code extract>
apr_pool_create(&pool, NULL);
allocator = serf_bucket_allocator_create(pool, NULL, NULL);
ssl_ctx = serf_bucket_mem_alloc(allocator, sizeof(*ssl_ctx));
</code extract>
The allocator used in serf_bucket_mem_alloc is the one from the new pool.
I've found a thread on dev@perl.apache.org with a similar stacktrace,
which points to pool debugging in apr/apr-util as the rootcause of
this issue. Possible?
[..]
Lieven
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=462&dsMessageId=2397561