Tcl Source Code

Therefore, the test for macOS is being disabled in [b7d236402fcec914] for 8.6+ for now, until the issue is resolved.

Thank you for having a look at this. I already figured, it was some kind of a hang, more complicated than a simple timeout.

So, fully agreed! +1

Still hanging :-(

Hmm, looks like it were different now for all 3 builds (xcode & 2 clang):

2026-09-14T10:59:24.2315740Z tcltest.test
...
2026-09-14T10:59:24.2316790Z ---- tcltest-4.1 start
2026-09-14T11:08:53.1772100Z ##[error]The action 'Run Tests' has timed out after 15 minutes.
-------------------------
2026-09-14T10:58:07.3118320Z tcltest.test
...
2026-09-14T10:58:07.3143360Z ---- tcltest-21.5 start
2026-09-14T11:13:16.6458290Z ##[error]The operation was canceled.
2026-09-14T11:13:16.6658760Z Post job cleanup.
-------------------------
2026-09-14T11:00:21.4613910Z tailcall.test
...
2026-09-14T11:00:21.4617130Z ---- tailcall-7 start
2026-09-14T11:13:04.2408000Z ##[error]The action 'Run Tests' has timed out after 20 minutes.

Something is completely wrong on macos side. Do we have people with mac to hand?

Huh, and test tcltest-4.1 has a constraint {unixOrWin}, how the test can trigger run for it on macos? Weird.

OK, looks like it doesn't detect mac at all, because tcl_platform(platform) is recognized as "unix".

See runs/34846833228/job/103984729723#step:5:14 :

**** osVersion 24.6.0 pointerSize 8 byteOrder littleEndian machine arm64 platform unix pathSeparator : os Darwin engine Tcl user runner wordSize 8 ****
**** unix ****
**** unixOrWin: 1, unix: 1, win: 0. mac: 0 ****

Hi, 
I've a macOS and i can do some tests if you want

nicolas

I don't know how it ever working properly, because $::tcl_platform(platform) is basically never "macintosh" (I didn't search for the revision yet, but even 8.5/8.6 seem to miss it (it is either dos, unix or windows, nothing else).

The fix (repairing tcltest) may look like this - GH/tcl/956856ba192179526fc12241f1bcb4ee1a540924:

    ConstraintInitializer unixOnly \
-	    {string equal $::tcl_platform(platform) unix}
+	    {expr {$::tcl_platform(platform) eq "unix" && $::tcl_platform(os) ne "Darwin"}}
    ConstraintInitializer macOnly \
-	    {string equal $::tcl_platform(platform) macintosh}
+	    {expr {$::tcl_platform(platform) eq "unix" && $::tcl_platform(os) eq "Darwin"}}
    ConstraintInitializer pcOnly \
	    {string equal $::tcl_platform(platform) windows}
    ConstraintInitializer winOnly \

An alternative fix may move this logic to TclpSetVariables(), and restore $::tcl_platform(platform) "macintosh" back. However it looks as too grave change to my taste.

I'm not really familiar with macos, so I'd like to delegate this decision to someone else. I'd firstly repair macos in tcltest only, but there are more places in source code checking for "macintosh".

> No platform decision is needed

Sure, as I wrote below it is temporary constraint to ignore test, till it is fixed properly.

> unixFCmd-2.4 passes on 8.6 and 9.0; on 9.0 the full `make test` with the CI settings gives 68144 tests, 0 failures, in 3 minutes.

Thx, I'll check it.

But as you can see on GH, more tests failing here and there (it is not unixFCmd-2.4 only), and they all are sporadic. The basic issue was a wrong constraints detection, repaired in [001fa14844a641c6] now. But you can try to fix another issues too.

Let's [f44aa91653bea8e8|try] sl1200mk2's proposed solution.

I agree with Don that changing existing constraints in tcltest is not a good idea: Any testcase which was written for the old Macintosh will - after this change - suddenly start failing when run under MacOS. Therefore, in the above commit, I reverted the changes to tcltest.tcl. Also, because we now know that macintosh is not supported any more, let's just remove the tempNotMac restrictions (since this is always 1) and change macOrUnix to unixOnly.

Tomorrow we will see if this works.

As already said (see below), it failed sporadically here and there, and some of the tests where it was hanging have nothing to do with fifo-detection fix at all.

I also committed the fix directly in GH (without changing the constraints back), but a bit simpler variant:

+    /*
+     * FIFOs do not have attributes, moreover calling copyfile() 
+     * could cause a blocking deadlock in the macOS VFS layer,
+     * see [7b4a819535231639].
+     */
+    if (S_ISFIFO(statBufPtr->st_mode)) {
+        return TCL_OK;
+    }

Looks good now - GH/runs/34888741662. Thus I'd add it to 8.6/9.0 (just to see who wins tomorrow ;)...
Let see if your branch would hang somewhere else.

Regarding the constraints - partially agree, but as already said it'd be rather task for someone with macos. Anyway, we can revert them if your branch passes the tests (and remain stable in few days).

So, what should happen with S_ISCHR/S_ISBLK/S_ISSOCK? Do they have attributes?

Your S_ISFIFO solution is the 'least change in functionality' solution, which is safest, so let's go for that (whether it actually fixes _this_ hang or not).

I don't think S_ISCHR, S_ISBLK, or S_ISSOCK will ever hang on Darwin's copyfile() function in the same way S_ISFIFO does. However they are also special file types, their underlying VFS structures handle read/write stream initialization differently. Also AIs seem to confirm that.

Although I wonder about another tests that was hanging previously... I don't believe there were a copy of PIPE attrs somewhere (stdout?). But lets see whether it'd hang later.

Closed now.