At 04:09 PM 5/29/2002, =?UTF-8?B?QnJhbmtvIMSMaWJlag==?= wrote:
>Branko ÄŒibej wrote:
>Ho hum. I think there's also a bug in apr_pool_initialize. The sequence
>there is
>
> apr_allocator_create(&global_allocator)
> apr_pool_create_ex(&global_pool, ...., global_allocator)
> apr_thread_mutex_create(&mutex, ...)
> apr_allocator_set_mutex(global_allocator, mutex)
>
>But apr_pool_create_ex will call apr_allocator_alloc on the provided
>allocator, and that will call apr_thread_mutex_lock ... on an
>uninitialized mutex, no less.
>
>At least, I /think/ that's the problem. Definitely all SVN tests on
>Windows are crashing in the mutex lock in apr_allocator_alloc, and that
>mutex definitely hasn't been initialized.
Well, if it helps, I've significantly overhauled the code for Win32 to
allow 'try'
semantics on Win32, which returned ENOTIMPL before. Possible this is
part of your headache.
We will now have a mutex object on 9x, a critical section on NT, unless we
explicitly request an APR_THREAD_MUTEX_UNNESTED flag to _create().
In that case, I've written an event-based model that's guaranteed to deadlock
on the same thread... maybe these issues are part of the problem you observed?
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sat Jun 1 14:23:19 2002