Re: Debugging hash contents

John Peacock <jpeacock@rowman.com> writes:

> I'm trying to complete the keywords-as-hash patch and I have triggered
> something too subtle for my dull mind to comprehend. I have one test
> failure (trans_tests number 1) which dumps core while trying to access
> the keywords hash. I've replicated to the best of my ability the
> exact processes involved (adding a bunch of files, some with already
> expanded keyword strings) and I cannot get it to fail in a repository
> of my own creation. It fails consistently when run inside the test
> tree.

One reason the tests might fail outside the test-suite is if your
.subversion/config has an effect, the test-suite uses --config-dir.

Just in case you don't know this already: it's possible to run the
python tests individually.

   $ cd subversion/tests/clients/cmdline
   $ path/to/trans_tests.py -v 1

That lets you identify the bit that fails, you can then edit
trans_tests.py to make it stop before the failure, rerun it and
finally run the command that fails manually.

> My question is, how do people conventionally examine the contents of
> apr hashes from within the debugger? There are times when nothing but
> a printf() equivalent will do, so I am consider writing a debugger
> function, apr_hash_dump, which will just print out the stringified
> hash keys and values. I don't see a better way to understand why the
> hash is not being populated correctly for this one case.

It could be incorrect memory use. On Linux some of these can be
detected by enabling APR's pool debugging and running the client under
valgrind.

-- 
Philip Martin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org