You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@subversion.apache.org by Kevin Radke <km...@gmail.com> on 2015/04/14 23:25:36 UTC
put_xlate_handle_node exception
I recently built svn 1.8.13 on a x64 Linux machine with self-built
dependencies that are current for Apache 2.2.29 (mpm=worker). I'm seeing
the following exception periodically and I'm looking for help to try and
figure out the cause.
httpd: subversion/libsvn_subr/utf.c:426: put_xlate_handle_node: Assertion
`node->next == ((void *)0)' failed.
[Tue Apr 14 16:12:40 2015] [notice] child pid 14683 exit signal Aborted (6)
Any pointers on what the assert is trying to protect against would be
helpful.
Thanks!
Kevin R.
Re: put_xlate_handle_node exception
Posted by Philip Martin <ph...@wandisco.com>.
Kevin Radke <km...@gmail.com> writes:
> So far the build without the --disable-nonportable-atomics flag seems to
> working much better with httpd 2.2.29, svn 1.8.13, and apr 1.5.1. I'm no
> longer seeing the assert when using the worker mpm on a heavily loaded
> multi-core system.
Interesting, I wonder if there is a bug in APR's generic atomic code or
if Subversion's use of the APR API is wrong?
--
Philip Martin | Subversion Committer
WANdisco // *Non-Stop Data*
Re: put_xlate_handle_node exception
Posted by Kevin Radke <km...@gmail.com>.
Philip,
So far the build without the --disable-nonportable-atomics flag seems to
working much better with httpd 2.2.29, svn 1.8.13, and apr 1.5.1. I'm no
longer seeing the assert when using the worker mpm on a heavily loaded
multi-core system.
Thanks!
Kevin R.
On Wed, Apr 15, 2015 at 11:26 AM, Kevin Radke <km...@gmail.com> wrote:
> Philip,
>
> I believe the non-portable-atomics flag is left over from getting 1.7
> working due to the original APR bug. Since the bug is fixed, I'll try
> without the flag and see what happens.
>
> A make check for this apr also succeeds without any issues.
>
> APR Lock Performance Test
> ==============
>
> apr_thread_mutex_t Tests
> Initializing the apr_thread_mutex_t (UNNESTED) OK
> Starting 1 threads OK
> microseconds: 24476 usec
> apr_thread_mutex_t Tests
> Initializing the apr_thread_mutex_t (NESTED) OK
> Starting 1 threads OK
> microseconds: 30257 usec
> apr_thread_rwlock_t Tests
> Initializing the apr_thread_rwlock_t OK
> Starting 1 threads OK
> microseconds: 42559 usec
> apr_thread_mutex_t Tests
> Initializing the apr_thread_mutex_t (UNNESTED) OK
> Starting 2 threads OK
> microseconds: 48643 usec
> apr_thread_mutex_t Tests
> Initializing the apr_thread_mutex_t (NESTED) OK
> Starting 2 threads OK
> microseconds: 49841 usec
> apr_thread_rwlock_t Tests
> Initializing the apr_thread_rwlock_t OK
> Starting 2 threads OK
> microseconds: 88017 usec
> apr_thread_mutex_t Tests
> Initializing the apr_thread_mutex_t (UNNESTED) OK
> Starting 3 threads OK
> microseconds: 71369 usec
> apr_thread_mutex_t Tests
> Initializing the apr_thread_mutex_t (NESTED) OK
> Starting 3 threads OK
> microseconds: 74264 usec
> apr_thread_rwlock_t Tests
> Initializing the apr_thread_rwlock_t OK
> Starting 3 threads OK
> microseconds: 156797 usec
> apr_thread_mutex_t Tests
> Initializing the apr_thread_mutex_t (UNNESTED) OK
> Starting 4 threads OK
> microseconds: 98064 usec
> apr_thread_mutex_t Tests
> Initializing the apr_thread_mutex_t (NESTED) OK
> Starting 4 threads OK
> microseconds: 99977 usec
> apr_thread_rwlock_t Tests
> Initializing the apr_thread_rwlock_t OK
> Starting 4 threads OK
> microseconds: 258812 usec
> apr_thread_mutex_t Tests
> Initializing the apr_thread_mutex_t (UNNESTED) OK
> Starting 5 threads OK
> microseconds: 122259 usec
> apr_thread_mutex_t Tests
> Initializing the apr_thread_mutex_t (NESTED) OK
> Starting 5 threads OK
> microseconds: 125806 usec
> apr_thread_rwlock_t Tests
> Initializing the apr_thread_rwlock_t OK
> Starting 5 threads OK
> microseconds: 344890 usec
> apr_thread_mutex_t Tests
> Initializing the apr_thread_mutex_t (UNNESTED) OK
> Starting 6 threads OK
> microseconds: 146183 usec
> apr_thread_mutex_t Tests
> Initializing the apr_thread_mutex_t (NESTED) OK
> Starting 6 threads OK
> microseconds: 149457 usec
> apr_thread_rwlock_t Tests
> Initializing the apr_thread_rwlock_t OK
> Starting 6 threads OK
> microseconds: 490974 usec
> Trying proc mutexes with mechanism `default'...
> Mutex mechanism `default' is global in scope on this platform.
> Trying global mutexes with mechanism `default'...
> no problems encountered...
> Trying proc mutexes with mechanism `flock'...
> Mutex mechanism `flock' is not global in scope on this platform.
> Trying global mutexes with mechanism `flock'...
> no problems encountered...
> Trying proc mutexes with mechanism `sysvsem'...
> Mutex mechanism `sysvsem' is global in scope on this platform.
> Trying global mutexes with mechanism `sysvsem'...
> no problems encountered...
> Trying proc mutexes with mechanism `posix'...
> Mutex mechanism `posix' is global in scope on this platform.
> Trying global mutexes with mechanism `posix'...
> no problems encountered...
> Trying proc mutexes with mechanism `fcntl'...
> Mutex mechanism `fcntl' is not global in scope on this platform.
> Trying global mutexes with mechanism `fcntl'...
> no problems encountered...
> Trying proc mutexes with mechanism `proc_pthread'...
> Mutex mechanism `proc_pthread' is global in scope on this platform.
> Trying global mutexes with mechanism `proc_pthread'...
> no problems encountered...
> testatomic : SUCCESS
>
> Kevin R.
>
> On Wed, Apr 15, 2015 at 10:30 AM, Philip Martin <
> philip.martin@wandisco.com> wrote:
>
>> Kevin Radke <km...@gmail.com> writes:
>>
>> > I'm using --disable-nonportable-atomics and apr 1.5.1 compiled with gcc
>> > 4.4.7.
>> > httpd 2.2.29 is built with mpm=worker.
>>
>> Do you have a particular reason for using --disable-nonportable-atomics?
>> I suspect it leads to code that is not used as often and thus less well
>> tested. Perhaps try building apr without that setting.
>>
>> > make check in svn gives:
>> > Summary of test results:
>> > 1948 tests PASSED
>> > 58 tests SKIPPED
>> > 31 tests XFAILED (1 WORK-IN-PROGRESS)
>> > SUMMARY: All tests successful.
>>
>> The APR regression tests probably exercise the atomic code more than the
>> Subversion regression tests.
>>
>> --
>> Philip Martin | Subversion Committer
>> WANdisco // *Non-Stop Data*
>>
>
>
Re: put_xlate_handle_node exception
Posted by Kevin Radke <km...@gmail.com>.
Philip,
I believe the non-portable-atomics flag is left over from getting 1.7
working due to the original APR bug. Since the bug is fixed, I'll try
without the flag and see what happens.
A make check for this apr also succeeds without any issues.
APR Lock Performance Test
==============
apr_thread_mutex_t Tests
Initializing the apr_thread_mutex_t (UNNESTED) OK
Starting 1 threads OK
microseconds: 24476 usec
apr_thread_mutex_t Tests
Initializing the apr_thread_mutex_t (NESTED) OK
Starting 1 threads OK
microseconds: 30257 usec
apr_thread_rwlock_t Tests
Initializing the apr_thread_rwlock_t OK
Starting 1 threads OK
microseconds: 42559 usec
apr_thread_mutex_t Tests
Initializing the apr_thread_mutex_t (UNNESTED) OK
Starting 2 threads OK
microseconds: 48643 usec
apr_thread_mutex_t Tests
Initializing the apr_thread_mutex_t (NESTED) OK
Starting 2 threads OK
microseconds: 49841 usec
apr_thread_rwlock_t Tests
Initializing the apr_thread_rwlock_t OK
Starting 2 threads OK
microseconds: 88017 usec
apr_thread_mutex_t Tests
Initializing the apr_thread_mutex_t (UNNESTED) OK
Starting 3 threads OK
microseconds: 71369 usec
apr_thread_mutex_t Tests
Initializing the apr_thread_mutex_t (NESTED) OK
Starting 3 threads OK
microseconds: 74264 usec
apr_thread_rwlock_t Tests
Initializing the apr_thread_rwlock_t OK
Starting 3 threads OK
microseconds: 156797 usec
apr_thread_mutex_t Tests
Initializing the apr_thread_mutex_t (UNNESTED) OK
Starting 4 threads OK
microseconds: 98064 usec
apr_thread_mutex_t Tests
Initializing the apr_thread_mutex_t (NESTED) OK
Starting 4 threads OK
microseconds: 99977 usec
apr_thread_rwlock_t Tests
Initializing the apr_thread_rwlock_t OK
Starting 4 threads OK
microseconds: 258812 usec
apr_thread_mutex_t Tests
Initializing the apr_thread_mutex_t (UNNESTED) OK
Starting 5 threads OK
microseconds: 122259 usec
apr_thread_mutex_t Tests
Initializing the apr_thread_mutex_t (NESTED) OK
Starting 5 threads OK
microseconds: 125806 usec
apr_thread_rwlock_t Tests
Initializing the apr_thread_rwlock_t OK
Starting 5 threads OK
microseconds: 344890 usec
apr_thread_mutex_t Tests
Initializing the apr_thread_mutex_t (UNNESTED) OK
Starting 6 threads OK
microseconds: 146183 usec
apr_thread_mutex_t Tests
Initializing the apr_thread_mutex_t (NESTED) OK
Starting 6 threads OK
microseconds: 149457 usec
apr_thread_rwlock_t Tests
Initializing the apr_thread_rwlock_t OK
Starting 6 threads OK
microseconds: 490974 usec
Trying proc mutexes with mechanism `default'...
Mutex mechanism `default' is global in scope on this platform.
Trying global mutexes with mechanism `default'...
no problems encountered...
Trying proc mutexes with mechanism `flock'...
Mutex mechanism `flock' is not global in scope on this platform.
Trying global mutexes with mechanism `flock'...
no problems encountered...
Trying proc mutexes with mechanism `sysvsem'...
Mutex mechanism `sysvsem' is global in scope on this platform.
Trying global mutexes with mechanism `sysvsem'...
no problems encountered...
Trying proc mutexes with mechanism `posix'...
Mutex mechanism `posix' is global in scope on this platform.
Trying global mutexes with mechanism `posix'...
no problems encountered...
Trying proc mutexes with mechanism `fcntl'...
Mutex mechanism `fcntl' is not global in scope on this platform.
Trying global mutexes with mechanism `fcntl'...
no problems encountered...
Trying proc mutexes with mechanism `proc_pthread'...
Mutex mechanism `proc_pthread' is global in scope on this platform.
Trying global mutexes with mechanism `proc_pthread'...
no problems encountered...
testatomic : SUCCESS
Kevin R.
On Wed, Apr 15, 2015 at 10:30 AM, Philip Martin <ph...@wandisco.com>
wrote:
> Kevin Radke <km...@gmail.com> writes:
>
> > I'm using --disable-nonportable-atomics and apr 1.5.1 compiled with gcc
> > 4.4.7.
> > httpd 2.2.29 is built with mpm=worker.
>
> Do you have a particular reason for using --disable-nonportable-atomics?
> I suspect it leads to code that is not used as often and thus less well
> tested. Perhaps try building apr without that setting.
>
> > make check in svn gives:
> > Summary of test results:
> > 1948 tests PASSED
> > 58 tests SKIPPED
> > 31 tests XFAILED (1 WORK-IN-PROGRESS)
> > SUMMARY: All tests successful.
>
> The APR regression tests probably exercise the atomic code more than the
> Subversion regression tests.
>
> --
> Philip Martin | Subversion Committer
> WANdisco // *Non-Stop Data*
>
Re: put_xlate_handle_node exception
Posted by Philip Martin <ph...@wandisco.com>.
Kevin Radke <km...@gmail.com> writes:
> I'm using --disable-nonportable-atomics and apr 1.5.1 compiled with gcc
> 4.4.7.
> httpd 2.2.29 is built with mpm=worker.
Do you have a particular reason for using --disable-nonportable-atomics?
I suspect it leads to code that is not used as often and thus less well
tested. Perhaps try building apr without that setting.
> make check in svn gives:
> Summary of test results:
> 1948 tests PASSED
> 58 tests SKIPPED
> 31 tests XFAILED (1 WORK-IN-PROGRESS)
> SUMMARY: All tests successful.
The APR regression tests probably exercise the atomic code more than the
Subversion regression tests.
--
Philip Martin | Subversion Committer
WANdisco // *Non-Stop Data*
Re: put_xlate_handle_node exception
Posted by Kevin Radke <km...@gmail.com>.
Philip,
I'm using --disable-nonportable-atomics and apr 1.5.1 compiled with gcc
4.4.7.
httpd 2.2.29 is built with mpm=worker.
make check in svn gives:
Summary of test results:
1948 tests PASSED
58 tests SKIPPED
31 tests XFAILED (1 WORK-IN-PROGRESS)
SUMMARY: All tests successful.
Kevin R,
On Wed, Apr 15, 2015 at 4:25 AM, Philip Martin <ph...@wandisco.com>
wrote:
> Kevin Radke <km...@gmail.com> writes:
>
> > I recently built svn 1.8.13 on a x64 Linux machine with self-built
> > dependencies that are current for Apache 2.2.29 (mpm=worker). I'm seeing
> > the following exception periodically and I'm looking for help to try and
> > figure out the cause.
> >
> >
> > httpd: subversion/libsvn_subr/utf.c:426: put_xlate_handle_node: Assertion
> > `node->next == ((void *)0)' failed.
> > [Tue Apr 14 16:12:40 2015] [notice] child pid 14683 exit signal Aborted
> (6)
> >
> >
> > Any pointers on what the assert is trying to protect against would be
> > helpful.
>
> The node pointer passed to put_xlate_handle_node() is obtained by
> calling get_xlate_handle_node() and all nodes returned by that function
> are expected to have node->next==NULL. If the assert fails it may
> indicate a threading problem, somehow a node is being used by multiple
> threads simultaneously. Which APR are you using? Is it build with
> portable or nonportable atomics? There was a bug in APR atomic
> operations in the past, perhaps you are seeing a variant of
> http://subversion.apache.org/docs/release-notes/1.7.html#rhel-2-issue
>
> --
> Philip Martin | Subversion Committer
> WANdisco // *Non-Stop Data*
>
Re: put_xlate_handle_node exception
Posted by Philip Martin <ph...@wandisco.com>.
Kevin Radke <km...@gmail.com> writes:
> I recently built svn 1.8.13 on a x64 Linux machine with self-built
> dependencies that are current for Apache 2.2.29 (mpm=worker). I'm seeing
> the following exception periodically and I'm looking for help to try and
> figure out the cause.
>
>
> httpd: subversion/libsvn_subr/utf.c:426: put_xlate_handle_node: Assertion
> `node->next == ((void *)0)' failed.
> [Tue Apr 14 16:12:40 2015] [notice] child pid 14683 exit signal Aborted (6)
>
>
> Any pointers on what the assert is trying to protect against would be
> helpful.
The node pointer passed to put_xlate_handle_node() is obtained by
calling get_xlate_handle_node() and all nodes returned by that function
are expected to have node->next==NULL. If the assert fails it may
indicate a threading problem, somehow a node is being used by multiple
threads simultaneously. Which APR are you using? Is it build with
portable or nonportable atomics? There was a bug in APR atomic
operations in the past, perhaps you are seeing a variant of
http://subversion.apache.org/docs/release-notes/1.7.html#rhel-2-issue
--
Philip Martin | Subversion Committer
WANdisco // *Non-Stop Data*