Bert Huijben <b...@qqmail.nl> writes: > I would guess that the actual keys are one byte longer than the length > passed to the hash function: a final '\0' to make them a c string. > > Does using a strdup instead of that memdup fix the problem? (Or memdup > with +1)
Are you referring to the patch below? >> Index: sw/subversion/src/subversion/libsvn_fs_fs/cached_data.c >> =================================================================== >> --- sw/subversion/src/subversion/libsvn_fs_fs/cached_data.c (revision >> 1571876) >> +++ sw/subversion/src/subversion/libsvn_fs_fs/cached_data.c (working copy) >> @@ -2050,7 +2050,10 @@ >> /* In incremental mode, update the hash; otherwise, write to the >> * final array. */ >> if (incremental) >> - apr_hash_set(hash, entry.key, entry.keylen, dirent); >> + apr_hash_set(hash, >> + apr_pstrmemdup(scratch_pool, entry.key, entry.keylen), >> + entry.keylen, >> + dirent); >> else >> APR_ARRAY_PUSH(entries, svn_fs_dirent_t *) = dirent; >> } I don't believe it makes a difference to this patch. This function doesn't care either way and the keys don't persist beyond this function. -- Philip Martin | Subversion Committer WANdisco // *Non-Stop Data*
