Careful with dem hashes...

Karl and I had a realization this morning that when you do

    apr_hash_set (hash, key, keylen, val);

The keys are *not* copied into the hash's internal pool.

Now, we've all been paranoid about duplicating value-objects before
storing them, but I wonder if folks have been applying this same
mentality to the key objects.

We need to be careful that the stored key isn't ever allocated in a
subpool that lives *below* the pool that the hash is in.

I've already searched through most of our codebase, but I don't know
enough to analyze two specific spots. Greg H? Jimb? You guys might
want to double-check.

(grepping for `apr_hash_set':)

In ./libsvn_delta/xml_output.c, line 281:
      apr_hash_set (att, "ancestor", strlen("ancestor"), ancestor_path);
In ./libsvn_delta/xml_output.c, line 283:
      apr_hash_set (att, "ver", strlen("ver"), svn_string_create (buf, pool));
In ./libsvn_fs/node.c, line 263:
  apr_hash_set (cache, id, id_size, 0);
In ./libsvn_fs/node.c, line 292:
  apr_hash_set (fs->node_cache, id, id_size, node);
In ./libsvn_fs/proplist.c, line 98:
      apr_hash_set (p->hash, name_copy, name->len, value_copy);
In ./libsvn_fs/proplist.c, line 208:
      apr_hash_set (copy, name_copy, name_len, value_copy);
In ./libsvn_fs/txn.c, line 328:
  apr_hash_set (fs->open_txns, txn->id, 0, txn);
Received on Sat Oct 21 14:36:12 2006