Re: allocate_string_data memory corruption

[Chong Yidong]

Eli Zaretskii <address@hidden> writes:

> Are you in fact 110% sure the abort happens on the second debugging
> check?  Can you tell how did you verify this?  (The line number shown
> by GDB is not a reliable evidence.)
>
> Was this code compiled without optimizations?  If not, recompile with
> "-O0" and see if you get abort or crash in another place.

I'll double-check with the user, but I believe it was compiled with
-O0.  We had to move the check around in that function while we were
narrowing down where the memory corruption occurs, and the line number
reported by GDB seemed to be correct.

> Btw, does the value of `data' itself change in any way?  You didn't
> show its value at the offending line.

`data' is just a variable, stored on the stack, that points to the
next free region of memory in current_sblock (b->next_free).  I
haven't considered the possibility that `data' itself could have
changed.  I'll look into it.