Karl's home net connection is down, and he's about to leave to catch a
train, but he says "Thank you!" And promises to remember the lesson
Greg Hudson <ghudson@MIT.EDU> writes:
> > 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