John E. Malmberg wrote:
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.
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.
I have confirmed that this is a bug that has apparently been in vms.c
for a while.
What seems to have happened is that when I moved the storage for the
filenames from the stack to the heap that it changed the memory access
patterns to expose the bug.
The problem is exposed with the input specification of:
"core.[0-9][0-9][0-9][0-9][0-9]" which is being parsed first as
DEV="core."
DIR="[0-9][0-9][0-9][0-9]"
Then the first "." is being interpreted as a directory delimiter a
little later which causes some other problems.
Obviously, a "[" should only indicate the start of a directory if it is
the start of the specification, or immediately preceded by a ":". But
that check apparently is not done anywhere in the code.
Apparently this specification should have been treated as a UNIX glob
specification, not as a potential VMS path.
I can easily fix this to not access violate, and with a little more work
get it to treat it as a UNIX specification and not a path.
I expect that this type of file specification will cause other problems
though, because of the strong assumptions in the VMS flavor of Perl that
"[" is a directory specification.
-John
[EMAIL PROTECTED]
Personal Opinion Only