> Greg Hudson recently checked in some major changes to the
> xml-tag-writing library; however, given that this bug has happened
> before, and Greg's changes seem to be working fine most of the time,
> I highly doubt that he introduced a bug... Rather, stimulated an old
> one.
I did, actually, fix a couple of pool handling problems when I checked
in those changes, and didn't find a good place to mention it (since I
also changed the function name). svn_xml_append_tag_hash was
allocating a subpool, passing it to svn_string_append* for a string
visible to the caller, and then destroying the pool, which is
distinctly naughty. Also, svn_xml_append_tag_v was leaking a bit of
memory from the calling pool to generate the temporary hash table; I
made it generate the hash into a subpool.
So, while I don't think I introduced any bugs, I certainly made
changes which could affect the reproduceability of an existing bug. I
will have a go at fixing the bug you describe myself, assuming I can
reproduce it.
[Read read read]
> That gets a reliable seg fault, but this time it corrupts data
> inside a subversion data structure (an edit baton) and may be easier
> to trace.
Hey, I recognize that bug. I had a very similar thing to happen to me
in the XML output editor. The problem is here:
eb = apr_palloc (subpool, sizeof (*edit_baton));
where edit_baton is a void **. Four bytes is not enough memory for an
editor baton. :) I will fix and see how much mileage that gets us.
In general, I found that if a structure is getting corrupted, the
first thing to check is whether you allocated enough memory for it,
given the APR pool system.
Received on Sat Oct 21 14:36:10 2006