Bert Huijben <b...@qqmail.nl> writes: > Strange… this should never be necessarily when *removing* something > from a hash (value =NULL). > > > I think you see some kind of other problem.
I agree this bit is unnecessary, I have changed it back. > @@ -2494,7 +2494,9 @@ read_dir_entries(apr_array_header_t *ent > { > /* We must be in incremental mode */ > assert(hash); > - apr_hash_set(hash, entry.key, entry.keylen, NULL); > + apr_hash_set(hash, > + apr_pstrmemdup(scratch_pool, entry.key, entry.keylen), > + entry.keylen, NULL); > continue; > } > This bit is the bug fix. It fixes some FAILs seen for fs-tests and valgrind identified memory reads after free. I wrote the fix in the wrong place first of all and then assumed I needed to fix it in both places. > @@ -2534,7 +2536,9 @@ read_dir_entries(apr_array_header_t *ent > /* 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_x__dirent_t *) = dirent; > } -- Philip Martin | Subversion Committer WANdisco // *Non-Stop Data*