Well, I've run a bunch of stress tests with Deadwood, both with gdb and with Valgrind. There are no errors nor (as an anonymous commenter thinks there might be) any memory leaks.
Since this anonymous commenter reports a glibc error (which, sadly, they did not have a chance to save), this indicates that there might be a double-free() situation. What I have done is revised reset_rem() to always make sure a given memory location is a non-null pointer before free()ing it, and making the memory pointer point to null after resetting it. I have also revised the code to initialize all "local" pointers as null pointers before being used.
The snapshot with these changes applied can be downloaded here:
The filename with an 'H' in it (head branch) is the version to look at.
OK, at this point, I'm closing the issue as being unreproducible. If anyone sees this and has a stack trace or any useful information, please let me know.
I have also revised the stable 2.3 branch of Deadwood by removing a spurious fflush from the hash (cache) code. Again, the download is in the same place, with an 'S' in the filename (stable branch).