Martin Wam <maw_at_esito.no> writes:
> I'm having some issues with dbx, but was able to extract the following
> stacktrace:
>
> Segmentation fault in apr_palloc at line 681 in file
> "memory/unix/apr_pools.c" ($t1)
> 681 active = pool->active;
> (dbx) where
> apr_palloc(pool = 0xfffeee88, in_size = 20), line 681 in "apr_pools.c"
> apr_mmap_create(new = 0x2ff21f34, file = 0x30097660, offset = 2, size =
> 1, flag = ??, cont = 0xfffeee88), line 100 in "mmap.c"
The code that calls apr_mmap_create() passes always passes a zero offset
here, so seeing offset=2 shows that something is wrong with the stack or
with dbx. size=1 is possible but suspiciously small.
If you build Subversion with apxs support you could try running the
Subversion HTTP regression tests. It might be worth building serf as
well. I know AIX is supposed to be binary compatible but a local build
might work better than a binary built on some other AIX system.
Another option would be to build APR without mmap support, and then
rebuild serf and Subversion using that APR. It might just crash
somewhere else but it will not crash in apr_mmap_create.
> serf_bucket_file_create() at 0xd259502c
> create_update_report_body() at 0xd256ddfc
> util.setup_request() at 0xd255f5a0
> setup_request_cb() at 0xd255f51c
> write_to_connection() at 0xd258ef10
> serf__process_connection() at 0xd258fd68
> serf_event_trigger() at 0xd258e278
> serf_context_run() at 0xd258e154
> update.finish_report() at 0xd256d838
> svn_wc_crawl_revisions5() at 0xd23d9c20
> update_internal() at 0xd23887ac
> svn_client__update_internal() at 0xd2388fd4
> svn_client__checkout_internal() at 0xd2387f2c
> svn_client_checkout3() at 0xd238805c
>
--
Philip Martin | Subversion Committer
WANdisco // *Non-Stop Data*
Received on 2015-01-23 13:20:25 CET