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?
[..]
Lieven
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=462&dsMessageId=2397561
Received on 2009-09-21 21:20:39 CEST