Help save net neutrality! Learn more.

#4722 8.5 head testsuite failures on windows


Six tests currently fail for 8.5 head on windows

==== async-4.3 async interrupting loop-less bytecode sequence FAILED
==== async-4.3 FAILED
==== filesystem-1.3 link normalisation FAILED
==== filesystem-1.3 FAILED
==== filesystem-1.4 link normalisation FAILED
==== filesystem-1.4 FAILED
==== stack-1.1 maxNestingDepth reached on infinite recursion FAILED
==== stack-1.1 FAILED
==== stack-3.1 enough room for regexp near recursion limit FAILED
==== stack-3.1 FAILED
==== tcltest-2.0 tcltest (verbose default - 'b') FAILED
==== tcltest-2.0 FAILED

The stack tests I am not sure about, I might have stack checking disabled (They were crashes).

The full test log is attached.


  • Jan Nijtmans

    Jan Nijtmans - 2011-10-29
    • assigned_to: nobody --> nijtmans
  • Jan Nijtmans

    Jan Nijtmans - 2011-10-29

    Looks like all failures, except filesystem-1.3
    and filesystem-1.4 are fixed already

  • Thomas Perschak

    Thomas Perschak - 2011-12-10

    I don't believe that theses tests, if failed, would cause tcl to crash?


  • Jan Nijtmans

    Jan Nijtmans - 2012-06-13

    Did a "fossil bisect" in order to try to find out which commit
    introduces this test failure. The result is:
    Changelog entry:
    2008-07-21 Andreas Kupries <>

    * generic/tclBasic.c: Extended the existing TIP #280 system (info
    * generic/tclCmdAH.c: frame), added the ability to track the
    * generic/tclCompCmds.c: absolute location of literal procedure
    * generic/tclCompile.c: arguments, and making this information
    * generic/tclCompile.h: available to uplevel, eval, and
    * generic/tclInterp.c: siblings. This allows proper tracking of
    * generic/tclInt.h: absolute location through custom (Tcl-coded)
    * generic/tclNamesp.c: control structures based on uplevel, etc.
    * generic/tclProc.c:

    However, I don't think this commit itself is to
    blame. It only changed the caching mechanism
    for literals, which apparently indirectly affects the
    normalization of file paths. It's really complicated!!!!!

    Also I found bug #1972879, which handles the
    caching of normalized paths. See pat Thoyts'
    remark in this issue regarding
    the failing test-cases filesystem-1.[34].
    These tests are already failing for
    almost 4 years!
    My current suspicion is that bug #1972879 is
    not fixed yet for some Windows paths, and that
    Andreas' commit only triggered it. The
    bug was there already before, but it only
    didn't manifest itself until Andreas' commit.

    The prove that this really is a caching issue:
    If I manually create a link to a directory
    with a file in it, the file normalization is OK,
    but running it from the test suite it is not.
    So the result highly depends from the

    Andreas, does this give some hint to you?

  • Jan Nijtmans

    Jan Nijtmans - 2012-06-13
    • labels: --> 36. Pathname Management
    • assigned_to: nijtmans --> andreas_kupries
  • Twylite

    Twylite - 2012-07-27

    A 32-bit tclsh build from tag 'core-8-5-12' using MSVC10, running on Windows 7 64-bit confirms that the only test failures that remain are filesystem-1.3 and filesystem-1.4.

    These two filesystem-* failures were also reported in #3545366 "Win32 link normalization test failures"; that bug has now been closed as a duplicate.

  • Twylite

    Twylite - 2012-07-27

    Issue affects core-8-5-branch and trunk.