At 11:21 PM -0500 12/14/05, John E. Malmberg wrote: >The bug seems to be in *mp_do_fileify_dirspec. > > else { /* This is a top-level dir. Add the MFD to the path. */ > if (buf) retspec = buf; > else if (ts) Newx(retspec,retlen+16,char); > else retspec = __fileify_retbuf; > cp1 = esa; > cp2 = retspec; > 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 have not had time to track down how it got to this state. I will try to >track that down tomorrow. > >At this point, the stack is already destroyed, so I will need to restart the >debugging run and trap all calls to mp_do_fileify_dirspec. > >I suspected the Newx statement because it could be making an incorrect >assumption about how much space is really needed, but the debugger is claiming >that ts is 0 so it should not have been executed. Of course with the stack >looking a bit corrupted, that could be wrong.
Note that one thing that was definitely happening is that we were passing the homegrown utime struct to the system utime() function. Change 26344 rolled back the inclusion of utime.h, but not until change 26358 today did the rest of the rollback happen. We can put this code back in once you post your changes to vms/vmsish.h, but for now we need to be consistent. I don't know for sure that this is what caused the stack corruption. I was seeing accvios until change #26358. -- ________________________________________ Craig A. Berry mailto:[EMAIL PROTECTED] "... getting out of a sonnet is much more difficult than getting in." Brad Leithauser