Tcl Source Code

View Ticket
Login
Ticket UUID: 2884203
Title: Crash in filesystem-9.5 test on Windows
Type: Bug Version: obsolete: 8.5.7
Submitter: patthoyts Created on: 2009-10-22 21:09:40
Subsystem: 37. File System Assigned To: dgp
Priority: 9 Immediate Severity:
Status: Closed Last Modified: 2009-10-28 03:31:25
Resolution: Fixed Closed By: dgp
    Closed on: 2009-10-27 20:31:25
Description:
We are getting a crash in filesystem-9.5, 9.6 and 9.7 on Windows XP and Windows 7 with core-8-5-branch.
I bisected the commits and this fault was introduced by the commit on 2009-08-20 by dgp:
 "* generic/tclPathObj.c: [Bug 2806250] Prevent the storage of strings ..."
The relevant part of the call stack looks like this:
MSVCRTD!memcpy
tcl85tg!Tcl_DuplicateObj
tcl85tg!AppendPath
tcl85tg!Tcl_FSGetNormalizedPath
tcl85tg!TclpMatchInDirectory
tcl85tg!Tcl_FSMatchInDirectory
tcl85tg!DoGlob
tcl85tg!DoGlob
tcl85tg!TclGlob
The crash occurs because in Tcl_DuplicateObj the objPtr->length is -1
I've checked on Windows XP and Windows 7 each time using MSVC6 to compile.
User Comments: dgp added on 2009-10-28 03:31:25:

allow_comments - 1


Patch applied to 8-5-branch and HEAD.

dgp added on 2009-10-28 03:26:19:

File Added - 348439: 2884203.patch

dgp added on 2009-10-28 03:25:17:
Here's the patch that fixes it.
Missing ref count.

dgp added on 2009-10-27 05:29:56:
In the AppendPath() call that leads to a crash,
both arguments are (Tcl_Obj *).  Can you report
the values of the respective typePtr fields?  I am
expecting each of them to be values of the "string"
Tcl_ObjType.

dgp added on 2009-10-27 05:14:20:
Any chance you are testing a build with
the TclNORM_LONG_PATH directive enabled?

The code in lines 2916-2938 of Revision 1.95.2.2
of tclWinFile.c do not appear able to handle the
case of lastValidPathEnd == NULL, which appears
to happen in the test case.

patthoyts added on 2009-10-24 05:39:11:
Applying this patch prevents the crash and the tests now pass.

dgp added on 2009-10-24 03:15:42:
Since HEAD is ok, see whether applying the
patch below to 8-5-branch makes it ok as well.

I still prefer to get a full understand to confirm the
best fix, but if this works it can be a second-best
solution to get 8.5.8 out.

Index: tclPathObj.c
===================================================================
RCS file: /cvsroot/tcl/tcl/generic/tclPathObj.c,v
retrieving revision 1.66.2.9
diff -u -r1.66.2.9 tclPathObj.c
--- tclPathObj.c        20 Aug 2009 14:59:53 -0000      1.66.2.9
+++ tclPathObj.c        23 Oct 2009 20:13:31 -0000
@@ -1457,6 +1457,9 @@

        if (PATHFLAGS(pathPtr) != 0
                && fsPathPtr->cwdPtr == cwdPtr) {
+#if 1
+           return fsPathPtr->normPathPtr
+#else
            pathPtr = fsPathPtr->normPathPtr;

            /* TODO: Determine how much, if any, of this forcing
@@ -1521,6 +1524,7 @@
            pathPtr->typePtr = &tclFsPathType;

            return pathPtr;
+#endif
        }
     }

patthoyts added on 2009-10-23 05:10:29:
Its the second call:
copy = AppendPath(dir, fsPathPtr->normPathPtr);
At this point 'dir' look like:
?dir
0x02a877b0
    refCount: 0x00000000
    bytes: 0x02a66030 "ÝÝ....ÝÝ"
    length: 0xffffffff
    typePtr: 0x00000000 {name=??? freeIntRepProc=??? dupIntRepProc=??? ...}
    internalRep: {longValue=0x02a87780 doubleValue=-6.2774360118698813e+066 otherValuePtr=0x02a87780 ...}

but fsPathPtr seems to be messed up:
?fsPathPtr
0x02a7aea8
    translatedPathPtr: 0x00000000 {refCount=??? bytes=??? length=??? ...}
    normPathPtr: 0x02a877e0 {refCount=0x00000001 bytes=0x02a984c0 "" length=0x00000004 ...}
    cwdPtr: 0x02a87888 {refCount=0x00000002 bytes=0x02a98530 "`û§Pÿ§" length=0x00000003 ...}
    flags: 0x00000001
    nativePathPtr: 0x00000000
    filesystemEpoch: 0x00000001
    fsRecPtr: 0x00653ac0 {clientData=0x00000000 fsPtr=0x10169c08 fileRefCount=0x0000002f ...}

HEAD is ok and filesystem.test passes all tests - so just 8.5 branch.

dgp added on 2009-10-23 04:55:08:
Does this show up on HEAD as well, or
only on core-8-5-branch?

dgp added on 2009-10-23 04:36:50:
Is it known which AppendPath() call in
Tcl_FSGNP() causes the crash?

Attachments: