On 09/22/06 16:32, Philip Martin wrote: > The first time the breakpoint is reached it's from the > svn_test__create_fs line, the second time it's from the > svn_fs_open_berkeley line. The key has the same value in each case, > and the second time that value is present in the cache, so the hash > lookup doesn't return NULL.
Hi Philip, It looks like the hash is getting updated fine during the initial create. However, on the second one it goes through init again and comes up with a new ht pointer. Digging into it I think I've found the problem in libapr0, although I was kind of rushed and didn't have time to test it because I'm leaving for a trip and out the door now. In any case, this looks like the culprit. apr_uint32_t apr_atomic_cas(volatile apr_uint32_t *mem, long with, long cmp) { long prev; #if APR_HAS_THREADS apr_thread_mutex_t *lock = hash_mutex[ATOMIC_HASH(mem)]; if (apr_thread_mutex_lock(lock) == APR_SUCCESS) { prev = *(long*)mem; if (prev == cmp) { *(long*)mem = with; } apr_thread_mutex_unlock(lock); return prev; On a 64-bit machine we end up with a size mismatch and a compare of junk. mem is defined as a pointer to a 32-bit, then a cast to long 64-bit in this case. prev ends up with junk it it and fails the compare prev == cmp that passes on a 32-bit box. In any case this is a bug, not positive if it's the only one. Troy
pgpXlshtL1lP9.pgp
Description: PGP signature