Craig A. Berry wrote:
At 11:21 PM -0500 12/14/05, John E. Malmberg wrote:
The bug seems to be in *mp_do_fileify_dirspec.
while (*cp1 != ':') *(cp2++) = *(cp1++);
With this value of esa, the while statement just runs away, and
will eventually cause *cp2 to write over something unless either *cp1
>> or *cp2 cause an access violation.
*VMS\mp_do_fileify_dirspec\%LINE 104099\esa: "[0-9][0-9][0-9][0-9"
I don't know for sure that this is what caused the stack corruption.
I was seeing accvios until change #26358.
I do not think that the utime() code is responsible.
The input specification is being treated as a rooted file specification
by an RMS parse flag. That is the only way it could take this code path
that I can see.
I do not know what the real cause is until I trace it down from the
beginning of the routine.
My suspicion though is that this bug has been there a while, but because
the stack based buffers were used, it would usually find a ":" and
terminate the loop before noticeable damage was done.
Notice that the while loop was not terminating on a trailing NULL if a
":" was not found.
And the input data string was on the command line to the dbgminiperl line.
This is where the debugger stopped on the access violation.
-John
[EMAIL PROTECTED]
Personal Opinion Only
