On 8/13/2025 9:52 AM, saito wrote:

I have a seldom used script that uses threads. I just found out that the new version breaks it; the script gets stuck.

The only change has been the Tcl version: I went from 8.6.10 to 8.6.16. The Thread package got upgraded too: from version 2.8.5 to 2.8.11.

I just ran the same script using the old version and it still runs fine. So the bug seems to be related to the upgrades.

Any ideas where to look for a potential cause?

Very simple example shows different behavior too:

package req Thread
set t [thread::create {thread::wait}]
thread::send  $t {set errorInfo}

can't read "errorInfo": no such variable

package req Thread
set t [thread::create {thread::wait}]
thread::send  $t {set ::errorInfo}

 can't read "::errorInfo": no such variable

Note, your choice of errorInfo can cause confusion. The first time you run that command, if the variable does not yet exist, (and I don't believe it will until there's been an error) then it will be set to a text string that says it doesn't exist, which
on a second try to read it will return the new contents, which would be the same text string as reported earlier.

To be sure, try [info global] or [info exist errorInfo].

Just curious, are you running on Windows?




But this was your example

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 8/13/2025 1:29 PM, et99 wrote:

But this was your example

Message got cut off, I was going to ask what your actual code was doing that didn't work, rather than this example.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 8/13/2025 3:52 PM, saito wrote:

On 8/13/2025 4:29 PM, et99 wrote:

Note, your choice of errorInfo can cause confusion. The first time you run that command, if the variable does not yet exist, (and I don't believe it will until there's been an error) then it will be set to a text string that says it doesn't exist,

which on a second try to read it will return the new contents, which would be the same text string as reported earlier.

To be sure, try [info global] or [info exist errorInfo].

I believe errorInfo is always available after you start a new tcl/wish shell. Same thing if you create a new thread. See the behavior in the old Thread version:

% package req Thread
2.8.5

% set t [thread::create {thread::wait}]
tid00003CE0

% thread::send  $t {set errorInfo}
can't read "::tcl_pkgPath": no such variable
    while executing
"foreach Dir $::tcl_pkgPath {
        if {$Dir ni $::auto_path} {
        lappend ::auto_path $Dir
        }
    }"

Just curious, are you running on Windows?

Yes, indeed this is on Windows 11.

I was going to ask what your actual code was doing that didn't work,

My code follows the typical threaded idea: it starts a new thread, sets up some variables, lets it do some file stuff, and then gets a status code at the end.

However, the package is acting differently. In my interactions today, it was getting stuck at different points. It almost seems like it is not being initialized properly and different errors pop up.

Below is what I see with magicsplat 8.6.16.

Notice that the thread does not initially have everything global setup, much less than in the mainthread. There's no errorInfo variable initially. It also doesn't have the auto_path setup fully either.

I mention this because you are doing file operations inside threads and a bug in the *tcl windows file system code* was discovered and patched just recently. The bug was when some code used memory that had been freed. So, it had a "timing" aspect to it.

In my case, the bug appeared as a (sometimes) failure to load packages inside of threads. The bug was also discovered to have been around for quite some time and I believe it was back-patched into 8.6 and is likely to be patched in the next 8.6 release.
It is patched/fixed in 9.1a0

You might want to get a magicsplat 9.0.2 and see if the problem is there also, and then see if 9.1a0 or later (when available) fixes the problem. You'd then know if you were being hit by this bug too.

=================================

(bin) 1 % package require Thread
2.8.11
(bin) 2 % set tid [thread::create {thread::wait}]
tid0000000000004288
(bin) 3 % thread::send $tid {info glob}
tcl_version auto_path env tcl_patchLevel tcl_library tcl_platform
(bin) 4 % thread::send $tid {join $auto_path \n} C:/Users/et/AppData/Local/Apps/Tcl86/lib/tcl8.6 C:/Users/et/AppData/Local/Apps/Tcl86/lib
(bin) 5 % info pa
8.6.16
(bin) 6 % join $auto_path \n
C:/Users/et/AppData/Local/Apps/Tcl86/lib/tcl8.6 C:/Users/et/AppData/Local/Apps/Tcl86/lib C:/Users/et/AppData/Local/Apps/Tcl86/lib/cawt3.1.1 C:/Users/et/AppData/Local/Apps/Tcl86/lib/tcl3d1.0.1 C:/Users/et/AppData/Local/Apps/Tcl86/lib/tcllib2.0 C:/Users/et/AppData/Local/Apps/Tcl86/lib/vfs1.4.2/template C:/Users/et/AppData/Local/Apps/Tcl86/lib/tk8.6 C:/Users/et/AppData/Local/Apps/Tcl86/lib/tk8.6/ttk

(bin) 8 % info glob
tcl_rcFileName tcl_version argv0 argv tcl_interactive tk_library tk_version auto_path errorCode tk_strictMotif errorInfo auto_index tid env tcl_patchLevel argc tk_patchLevel tcl_library tcl_platform

(bin) 9 % thread::send $tid {package require foobar}
can't find package foobar
(bin) 10 % thread::send $tid {set errorInfo}
can't find package foobar
while executing
"package require foobar"

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

saito <[email protected]> wrote:

On 8/13/2025 4:29 PM, et99 wrote:

Note, your choice of errorInfo can cause confusion. The first time you
run that command, if the variable does not yet exist, (and I don't
believe it will until there's been an error) then it will be set to a
text string that says it doesn't exist, which on a second try to read it
will return the new contents, which would be the same text string as
reported earlier.

To be sure, try [info global] or [info exist errorInfo].

I believe errorInfo is always available after you start a new tcl/wish
shell.

It is not, it is only created when the first "error" occurs that would
cause it to appear:

$ rlwrap tclsh
% set tcl_patchLevel
8.6.12
% info exists ::errorInfo
0
%

$ rlwrap tclsh
% set tcl_patchLevel
8.6.12
% package require Thread
2.8.7
% set t [thread::create {thread::wait}]
tid0x7fb63b2bc640
% thread::send $t {info exists ::errorInfo}
0
%

It does not exist in the main interpreter, nor in the interpreter in
the single thread, when the interpreters are created.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Am 14.08.2025 um 17:49 schrieb saito:

On 8/14/2025 8:22 AM, Rich wrote:

saito <[email protected]> wrote:

I believe errorInfo is always available after you start a new tcl/wish
shell.

It is not, it is only created when the first "error" occurs that would
cause it to appear:

     $ rlwrap tclsh
     % set tcl_patchLevel
     8.6.12
     % info exists ::errorInfo
     0
     %

...

It does not exist in the main interpreter, nor in the interpreter in
the single thread, when the interpreters are created.

Interesting. On Windows, this is what I see from wish or tkcon:

1 % info exists errorInfo
1
2 % info patchlevel
8.6.16
3 %
3 % info exists ::errorInfo
1

But from tclsh, which I never use, I get the same result as you above.

Yes, a lot of tk bindings use "catch" and leave info in the error variable. That isd as it is.>

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

saito <[email protected]> wrote:

On 8/14/2025 8:22 AM, Rich wrote:

saito <[email protected]> wrote:

I believe errorInfo is always available after you start a new tcl/wish
shell.

It is not, it is only created when the first "error" occurs that would
cause it to appear:

$ rlwrap tclsh
% set tcl_patchLevel
8.6.12
% info exists ::errorInfo
0
%

...

It does not exist in the main interpreter, nor in the interpreter in
the single thread, when the interpreters are created.

Interesting. On Windows, this is what I see from wish or tkcon:

1 % info exists errorInfo
1
2 % info patchlevel
8.6.16
3 %
3 % info exists ::errorInfo
1

But from tclsh, which I never use, I get the same result as you above.

Retesting with wish, yes, the errorInfo global exists on a brand newly
started 'wish'.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)