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.

Reply via email to