From Newsgroup: comp.lang.tcl

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
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.lang.tcl

On 8/13/2025 12:52 PM, 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.

I was a bit frustrated so I replaced Thread v2.8.11 with the old version v2.8.5 in the new install of Tcl v8.6.16.

Like magic, everything is working fine again.

I am not sure if this is a bug or something else but there is a
significant behavior change in Threads v2.8.11. I checked the docs but
I didn't come across any explanation.




--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.lang.tcl

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
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.lang.tcl

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.

--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.lang.tcl

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.








--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.lang.tcl

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"



--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.lang.tcl

saito <saitology9@gmail.com> 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.

--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.lang.tcl

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

saito <saitology9@gmail.com> 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.

--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.lang.tcl

On 8/13/2025 9:52 PM, et99 wrote:

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.

Thanks for the detailed info. You know this matches very nicely with
what I was seeing. I will try to test it over the weekend. But restoring
the old version of Thread fixed it for me.
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.lang.tcl

Am 14.08.2025 um 17:49 schrieb saito:

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

saito <saitology9@gmail.com> 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.>

--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.lang.tcl

saito <saitology9@gmail.com> wrote:

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

saito <saitology9@gmail.com> 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'.
--- Synchronet 3.21a-Linux NewsLink 1.2