On Mar 5, 2018, at 10:54 PM, Myria <myriac...@gmail.com> wrote: > > Final email for the night >.< > > What's clobbering the expanded_size is this in build_rep_list: > > /* The value as stored in the data struct. > 0 is either for unknown length or actually zero length. */ > *expanded_size = first_rep->expanded_size; > > first_rep->expanded_size here is zero for the last call to this > function before the error. In every other case before the error, the > two values are equal. > > Then this code executes: > > if (*expanded_size == 0) > if (rep_header->type == svn_fs_fs__rep_plain || first_rep->size != 4) > *expanded_size = first_rep->size; > > first_rep->size is 16384, and this is why rb->len becomes 16384, > leading to the error. > > I don't know what all this code is doing, but that's the proximate > cause of the failure. > > Melissa
Has it been possible to determine what is setting expanded_size to 0 before that last call? I wonder if there is specific logic that decides (perhaps incorrectly?) to do that? Alternatively is it being clobbered by some out-of-bounds access, use-after-free, or another such issue? Is it possible in your debugger setup to determine the address of that variable and set a breakpoint that triggers when that memory is written? (It may be called a watchpoint?) Which leads me to another thought: if you can set such a breakpoint / watchpoint and it does not trigger, then this expanded_size might not be the same instance in that final call. Perhaps a shallow copy of an enclosing structure is made which leaves out the known size and sets it to 0 for some reason, and that final call is given that (incomplete) copy. Caveat: I am not familiar with the codebase but these are my thoughts based on adventures in other code bases.
