Stack corruption in 21.5b26
Fabrice Popineau
Fabrice.Popineau at supelec.fr
Tue May 16 02:38:51 EDT 2006
* Aidan Kehoe <kehoea at parhasard.net> writes:
> Ar an triú lá déag de mí Bealtaine, scríobh Fabrice Popineau:
>> I managed to compile the latest CVS natively under Win32 (and
>> using my own setup ;-) but while trying the debug version, I got
>> a stack corruption. The following patch cures it.
> Cool, thank you for tracking it down. But are you sure the
> corruption appears after Stephen~s patch of
> http://mid.gmane.org/87slnt7nrq.fsf_-_@tleepslib.sk.tsukuba.ac.jp
> was committed? Because the first part of it looks like it would
> have roughly the same effect on the stack as Stephen~s fix, and
> the second part is an change to old code that~s been around for
> ten years without provoking a bug.
Not at all. Stephen's patch was abour enlarging the buffer. But that
doesn't cure the fact that :
Ibyte buf[DOC_MAX_FILENAME_LENGTH+1];
Ibyte *buffer = buf;
int buffer_size = sizeof (buf), space_left;
^^^^^^^^^^^^
whatever the size of the buf[] array, buffer_size is set to this size.
REGISTER Ibyte *p = buffer;
p and buffer point to the same location
space_left = buffer_size - (p - buffer);
space_left is buffer_size
while (space_left > 0)
{
int nread;
nread = Lstream_read (XLSTREAM (instream), p, space_left);
You read buffer_size characters into buf[0 .. buffer_size - 1] that is the buf[] array is full
p[nread] = 0;
^^^^^^^^^^^^^^^^^^^
and then you are accessing p[buffer_size] which is prohibited whatever
the real size of the buffer is, because your buf index goes from 0 to
buffer_size - 1.
I fixed it in both places but I can acknowledge only for the first one
causing a crash.
Fabrice
More information about the XEmacs-Beta
mailing list