On Sep 21, 2009, at 3:20 PM, Lieven Govaerts wrote:
> On Tue, Jul 21, 2009 at 2:10 AM, Hyrum K. Wright <hyrum_at_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_at_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
Received on 2009-09-23 15:14:31 CEST