I'm running on a virtual pop-os (ubuntu) and the below script will crash
tclsh every so often but not every time.

This is a whittled down version of a larger program which repeats the
errors. Many errors seem to be related to memory allocation. When I run
it in gdb and do a backtrace, I see mentions of malloc problems. Using
valgrind reports errors too.

When I only create one thread, it ran over 400 times w/o a crash.

See at the bottom some output. I run a script with 1000's of lines of
the same command.

I believe I saw a crash on simply doing the package require Tk, but it
took many times before that crashed. It happens much more often with
this code below.

Can I safely assume it's not the fault of my script, but rather some bug
in tcl?

Here's the script:

#####################################
package require Thread

set script {
proc putz {arg color } {
if { ![info exist ::t_putz] } {
set ::t_putz 1
package require Tk

text .ttttt
pack .ttttt -side left -fill both -expand 1

.ttttt tag configure normal -foreground black
.ttttt tag configure red -foreground red -font {courier 10}
}
catch {
.ttttt insert end $arg\n $color
.ttttt see end
update
}

}
for {set n 0} {$n < 6 } {incr n} {
putz "Testing $n" normal
putz "Testing $n" red
}
thread::wait

}

proc wait { ms } {
after $ms set ::__sleep__tmp 1
vwait ::__sleep__tmp
}

thread::create $script
thread::create $script ;# with 2 or more threads it will crash


wait 2500
puts done
exit
#####################################


----------- here's a bit of the output ----------

bash script file runalot:

/usr/bin/tclsh crash.tcl
/usr/bin/tclsh crash.tcl
/usr/bin/tclsh crash.tcl
... 1000 repeats ....


$ bash runalot.sh >temp

Xlib: charsets ISO8859-1:GL and ISO8859-1:GL have the same CT sequence runalot.sh: line 3: 50593 Segmentation fault /usr/bin/tclsh crash.tcl runalot.sh: line 4: 50597 Segmentation fault /usr/bin/tclsh crash.tcl Xlib: charsets ISO8859-1:GL and ISO8859-1:GL have the same CT sequence
Xlib: charsets ISO8859-1:GR and ISO8859-1:GR have the same CT sequence
Xlib: charsets CNS11643.1986-1:GL and CNS11643.1986-1:GL have the same
CT sequence
Xlib: charsets CNS11643.1992-7:GR and CNS11643.1992-7:GR have the same
CT sequence
runalot.sh: line 5: 50601 Segmentation fault /usr/bin/tclsh crash.tcl runalot.sh: line 6: 50605 Segmentation fault /usr/bin/tclsh crash.tcl runalot.sh: line 10: 50623 Segmentation fault /usr/bin/tclsh crash.tcl runalot.sh: line 11: 50627 Segmentation fault /usr/bin/tclsh crash.tcl runalot.sh: line 16: 50647 Segmentation fault /usr/bin/tclsh crash.tcl Xlib: charsets ISO8859-1:GL and ISO8859-1:GL have the same CT sequence
Xlib: charsets ISO8859-1:GR and ISO8859-1:GR have the same CT sequence
Xlib: charsets ISO8859-14:GR and ISO8859-14:GR have the same CT sequence
Xlib: charsets CNS11643.1986-2:GR and CNS11643.1986-2:GR have the same
CT sequence
Xlib: charsets ISO10646-1 and ISO10646-1 have the same CT sequence
runalot.sh: line 18: 50655 Segmentation fault /usr/bin/tclsh crash.tcl runalot.sh: line 20: 50663 Segmentation fault /usr/bin/tclsh crash.tcl runalot.sh: line 21: 50667 Segmentation fault /usr/bin/tclsh crash.tcl runalot.sh: line 23: 50675 Segmentation fault /usr/bin/tclsh crash.tcl runalot.sh: line 28: 50696 Segmentation fault /usr/bin/tclsh crash.tcl runalot.sh: line 29: 50700 Segmentation fault /usr/bin/tclsh crash.tcl runalot.sh: line 32: 50713 Segmentation fault /usr/bin/tclsh crash.tcl runalot.sh: line 33: 50717 Segmentation fault /usr/bin/tclsh crash.tcl Xlib: charsets ISO8859-1:GL and ISO8859-1:GL have the same CT sequence runalot.sh: line 42: 50753 Segmentation fault /usr/bin/tclsh crash.tcl runalot.sh: line 49: 50781 Segmentation fault /usr/bin/tclsh crash.tcl runalot.sh: line 54: 50801 Segmentation fault /usr/bin/tclsh crash.tcl runalot.sh: line 57: 50813 Segmentation fault /usr/bin/tclsh crash.tcl runalot.sh: line 62: 50833 Segmentation fault /usr/bin/tclsh crash.tcl Xft: locking error too many file unlocks
Xft: locking error too many file unlocks
Xft: locking error too many file unlocks
Xft: locking error too many file unlocks
Xft: locking error too many file unlocks
Xft: locking error too many file unlocks
Xft: locking error too many file unlocks
Xft: locking error too many file unlocks
Xft: locking error too many file unlocks
Xft: locking error too many file unlocks
Xft: locking error too many file unlocks
Xft: locking error too many file unlocks
... lots more lines of this ...
^C

}





valgrind says this:

[1382]$ valgrind tclsh crash.tcl
==52771== Memcheck, a memory error detector
==52771== Copyright (C) 2002-2017, and GNU GPL'd, by Julian Seward et al. ==52771== Using Valgrind-3.14.0 and LibVEX; rerun with -h for copyright info ==52771== Command: tclsh crash.tcl
==52771==
==52771== Thread 2:
==52771== Invalid read of size 1
==52771== at 0x483CCD3: strcmp (in /usr/lib/x86_64-linux-gnu/valgrind/vgpreload_memcheck-amd64-linux.so)
==52771== by 0x78EBDEE: _XimUnRegisterIMInstantiateCallback (in /usr/lib/x86_64-linux-gnu/libX11.so.6.3.0)
==52771== by 0x78D3300: XUnregisterIMInstantiateCallback (in /usr/lib/x86_64-linux-gnu/libX11.so.6.3.0)
==52771== by 0x78EBCAD: _XimRegisterIMInstantiateCallback (in /usr/lib/x86_64-linux-gnu/libX11.so.6.3.0)
==52771== by 0x78D327A: XRegisterIMInstantiateCallback (in /usr/lib/x86_64-linux-gnu/libX11.so.6.3.0)
==52771== by 0x75A13DB: TkpOpenDisplay (in /usr/lib/x86_64-linux-gnu/libtk8.6.so)
==52771== by 0x750A641: ??? (in /usr/lib/x86_64-linux-gnu/libtk8.6.so) ==52771== by 0x750A4AF: ??? (in /usr/lib/x86_64-linux-gnu/libtk8.6.so) ==52771== by 0x750AE7B: TkCreateMainWindow (in /usr/lib/x86_64-linux-gnu/libtk8.6.so)
==52771== by 0x751585D: ??? (in /usr/lib/x86_64-linux-gnu/libtk8.6.so) ==52771== by 0x7515258: ??? (in /usr/lib/x86_64-linux-gnu/libtk8.6.so) ==52771== by 0x750D31C: ??? (in /usr/lib/x86_64-linux-gnu/libtk8.6.so) ==52771== Address 0x697a930 is 0 bytes inside a block of size 9 free'd ==52771== at 0x483997B: free (in /usr/lib/x86_64-linux-gnu/valgrind/vgpreload_memcheck-amd64-linux.so)
==52771== by 0x78E22DC: XSetLocaleModifiers (in /usr/lib/x86_64-linux-gnu/libX11.so.6.3.0)
==52771== by 0x75A1B26: ??? (in /usr/lib/x86_64-linux-gnu/libtk8.6.so) ==52771== by 0x75A1AAB: ??? (in /usr/lib/x86_64-linux-gnu/libtk8.6.so) ==52771== by 0x78EBCAD: _XimRegisterIMInstantiateCallback (in /usr/lib/x86_64-linux-gnu/libX11.so.6.3.0)
==52771== by 0x78D327A: XRegisterIMInstantiateCallback (in /usr/lib/x86_64-linux-gnu/libX11.so.6.3.0)
==52771== by 0x75A13DB: TkpOpenDisplay (in /usr/lib/x86_64-linux-gnu/libtk8.6.so)
==52771== by 0x750A641: ??? (in /usr/lib/x86_64-linux-gnu/libtk8.6.so) ==52771== by 0x750A4AF: ??? (in /usr/lib/x86_64-linux-gnu/libtk8.6.so) ==52771== by 0x750AE7B: TkCreateMainWindow (in /usr/lib/x86_64-linux-gnu/libtk8.6.so)
==52771== by 0x751585D: ??? (in /usr/lib/x86_64-linux-gnu/libtk8.6.so) ==52771== by 0x7515258: ??? (in /usr/lib/x86_64-linux-gnu/libtk8.6.so) ==52771== Block was alloc'd at
==52771== at 0x483874F: malloc (in /usr/lib/x86_64-linux-gnu/valgrind/vgpreload_memcheck-amd64-linux.so)
==52771== by 0x78E1ED4: _XlcDefaultMapModifiers (in /usr/lib/x86_64-linux-gnu/libX11.so.6.3.0)
==52771== by 0x78E22C5: XSetLocaleModifiers (in /usr/lib/x86_64-linux-gnu/libX11.so.6.3.0)
==52771== by 0x75A1B26: ??? (in /usr/lib/x86_64-linux-gnu/libtk8.6.so) ==52771== by 0x75A13C3: TkpOpenDisplay (in /usr/lib/x86_64-linux-gnu/libtk8.6.so)
==52771== by 0x750A641: ??? (in /usr/lib/x86_64-linux-gnu/libtk8.6.so) ==52771== by 0x750A4AF: ??? (in /usr/lib/x86_64-linux-gnu/libtk8.6.so) ==52771== by 0x750AE7B: TkCreateMainWindow (in /usr/lib/x86_64-linux-gnu/libtk8.6.so)
==52771== by 0x751585D: ??? (in /usr/lib/x86_64-linux-gnu/libtk8.6.so) ==52771== by 0x7515258: ??? (in /usr/lib/x86_64-linux-gnu/libtk8.6.so) ==52771== by 0x750D31C: ??? (in /usr/lib/x86_64-linux-gnu/libtk8.6.so) ==52771== by 0x495F7A8: ??? (in /usr/lib/x86_64-linux-gnu/libtcl8.6.so) ==52771==
==52771== Invalid read of size 1
==52771== at 0x483CCF4: strcmp (in /usr/lib/x86_64-linux-gnu/valgrind/vgpreload_memcheck-amd64-linux.so)
==52771== by 0x78EBDEE: _XimUnRegisterIMInstantiateCallback (in /usr/lib/x86_64-linux-gnu/libX11.so.6.3.0)
==52771== by 0x78D3300: XUnregisterIMInstantiateCallback (in /usr/lib/x86_64-linux-gnu/libX11.so.6.3.0)
==52771== by 0x78EBCAD: _XimRegisterIMInstantiateCallback (in /usr/lib/x86_64-linux-gnu/libX11.so.6.3.0)
==52771== by 0x78D327A: XRegisterIMInstantiateCallback (in /usr/lib/x86_64-linux-gnu/libX11.so.6.3.0)
==52771== by 0x75A13DB: TkpOpenDisplay (in /usr/lib/x86_64-linux-gnu/libtk8.6.so)
==52771== by 0x750A641: ??? (in /usr/lib/x86_64-linux-gnu/libtk8.6.so) ==52771== by 0x750A4AF: ??? (in /usr/lib/x86_64-linux-gnu/libtk8.6.so) ==52771== by 0x750AE7B: TkCreateMainWindow (in /usr/lib/x86_64-linux-gnu/libtk8.6.so)
==52771== by 0x751585D: ??? (in /usr/lib/x86_64-linux-gnu/libtk8.6.so) ==52771== by 0x7515258: ??? (in /usr/lib/x86_64-linux-gnu/libtk8.6.so) ==52771== by 0x750D31C: ??? (in /usr/lib/x86_64-linux-gnu/libtk8.6.so) ==52771== Address 0x697a931 is 1 bytes inside a block of size 9 free'd ==52771== at 0x483997B: free (in /usr/lib/x86_64-linux-gnu/valgrind/vgpreload_memcheck-amd64-linux.so)
==52771== by 0x78E22DC: XSetLocaleModifiers (in /usr/lib/x86_64-linux-gnu/libX11.so.6.3.0)
==52771== by 0x75A1B26: ??? (in /usr/lib/x86_64-linux-gnu/libtk8.6.so) ==52771== by 0x75A1AAB: ??? (in /usr/lib/x86_64-linux-gnu/libtk8.6.so) ==52771== by 0x78EBCAD: _XimRegisterIMInstantiateCallback (in /usr/lib/x86_64-linux-gnu/libX11.so.6.3.0)
==52771== by 0x78D327A: XRegisterIMInstantiateCallback (in /usr/lib/x86_64-linux-gnu/libX11.so.6.3.0)
==52771== by 0x75A13DB: TkpOpenDisplay (in /usr/lib/x86_64-linux-gnu/libtk8.6.so)
==52771== by 0x750A641: ??? (in /usr/lib/x86_64-linux-gnu/libtk8.6.so) ==52771== by 0x750A4AF: ??? (in /usr/lib/x86_64-linux-gnu/libtk8.6.so) ==52771== by 0x750AE7B: TkCreateMainWindow (in /usr/lib/x86_64-linux-gnu/libtk8.6.so)
==52771== by 0x751585D: ??? (in /usr/lib/x86_64-linux-gnu/libtk8.6.so) ==52771== by 0x7515258: ??? (in /usr/lib/x86_64-linux-gnu/libtk8.6.so) ==52771== Block was alloc'd at
==52771== at 0x483874F: malloc (in /usr/lib/x86_64-linux-gnu/valgrind/vgpreload_memcheck-amd64-linux.so)
==52771== by 0x78E1ED4: _XlcDefaultMapModifiers (in /usr/lib/x86_64-linux-gnu/libX11.so.6.3.0)
==52771== by 0x78E22C5: XSetLocaleModifiers (in /usr/lib/x86_64-linux-gnu/libX11.so.6.3.0)
==52771== by 0x75A1B26: ??? (in /usr/lib/x86_64-linux-gnu/libtk8.6.so) ==52771== by 0x75A13C3: TkpOpenDisplay (in /usr/lib/x86_64-linux-gnu/libtk8.6.so)
==52771== by 0x750A641: ??? (in /usr/lib/x86_64-linux-gnu/libtk8.6.so) ==52771== by 0x750A4AF: ??? (in /usr/lib/x86_64-linux-gnu/libtk8.6.so) ==52771== by 0x750AE7B: TkCreateMainWindow (in /usr/lib/x86_64-linux-gnu/libtk8.6.so)
==52771== by 0x751585D: ??? (in /usr/lib/x86_64-linux-gnu/libtk8.6.so) ==52771== by 0x7515258: ??? (in /usr/lib/x86_64-linux-gnu/libtk8.6.so) ==52771== by 0x750D31C: ??? (in /usr/lib/x86_64-linux-gnu/libtk8.6.so) ==52771== by 0x495F7A8: ??? (in /usr/lib/x86_64-linux-gnu/libtcl8.6.so) ==52771==
done
==52771==
==52771== HEAP SUMMARY:
==52771== in use at exit: 3,328,503 bytes in 1,543 blocks
==52771== total heap usage: 3,342 allocs, 1,799 frees, 6,809,843 bytes allocated
==52771==
==52771== LEAK SUMMARY:
==52771== definitely lost: 560 bytes in 2 blocks
==52771== indirectly lost: 16,921 bytes in 165 blocks
==52771== possibly lost: 3,036,045 bytes in 355 blocks
==52771== still reachable: 274,977 bytes in 1,021 blocks
==52771== suppressed: 0 bytes in 0 blocks
==52771== Rerun with --leak-check=full to see details of leaked memory ==52771==
==52771== For counts of detected and suppressed errors, rerun with: -v ==52771== ERROR SUMMARY: 9 errors from 2 contexts (suppressed: 0 from 0)

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

On 9/17/2021 1:43 PM, ted brown wrote:

On 9/17/2021 1:27 PM, Rich wrote:

ted brown <tedbrown888@gmail.com> wrote:

I'm running on a virtual pop-os (ubuntu) and the below script will
crash tclsh every so often but not every time.

I made this mod to get it to finally crash:

for {set i 0} {$i < 5} {incr i} {
thread::create $script
thread::create $script   ;# with 2 or more threads it will crash
}

$i < 5 does not crash
$i < 6 does crash

Slackware (on a real system, not a VM) using Tcl 8.6.11.

And the crash output looks like it is caused by a resource issue with
the X server.  But I don't know enough about the inner workings of xlib
to say more than that.

Thanks for verifying that Rich on some real hardware, not a vm. I also
forgot to mention that I don't have any problems with the full version
of the program on windows 10 with 8.6.10.

My linux version is 8.6.9

I'll see if anyone else has something to add before submitting a ticket.

I just tried Rich's change to run more threads, and got an interesting
output, don't know what xcb is, but it seems on target:


Xft: locking error too many file unlocks
Xft: locking error too many file unlocks
runalot.sh: line 19: 53611 Segmentation fault /usr/bin/tclsh crash.tcl Xlib: charsets ISO8859-3:GR and ISO8859-3:GR have the same CT sequence
Xlib: charsets ISO8859-13:GR and ISO8859-13:GR have the same CT sequence

[xcb] Unknown request in queue while appending request
[xcb] Most likely this is a multi-threaded client and XInitThreads has
not been called
[xcb] Aborting, sorry about that.

tclsh: ../../src/xcb_io.c:151: append_pending_request: Assertion `!xcb_xlib_unknown_req_pending' failed.
runalot.sh: line 24: 53671 Aborted /usr/bin/tclsh crash.tcl runalot.sh: line 26: 53695 Segmentation fault /usr/bin/tclsh crash.tcl runalot.sh: line 29: 53734 Segmentation fault /usr/bin/tclsh crash.tcl

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

ted brown <tedbrown888@gmail.com> wrote:

I'm running on a virtual pop-os (ubuntu) and the below script will
crash tclsh every so often but not every time.

I made this mod to get it to finally crash:

for {set i 0} {$i < 5} {incr i} {
thread::create $script
thread::create $script ;# with 2 or more threads it will crash
}

$i < 5 does not crash
$i < 6 does crash

Slackware (on a real system, not a VM) using Tcl 8.6.11.

And the crash output looks like it is caused by a resource issue with
the X server. But I don't know enough about the inner workings of xlib
to say more than that.

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

On 9/17/2021 1:27 PM, Rich wrote:

ted brown <tedbrown888@gmail.com> wrote:

I'm running on a virtual pop-os (ubuntu) and the below script will
crash tclsh every so often but not every time.

I made this mod to get it to finally crash:

for {set i 0} {$i < 5} {incr i} {
thread::create $script
thread::create $script ;# with 2 or more threads it will crash
}

$i < 5 does not crash
$i < 6 does crash

Slackware (on a real system, not a VM) using Tcl 8.6.11.

And the crash output looks like it is caused by a resource issue with
the X server. But I don't know enough about the inner workings of xlib
to say more than that.

Thanks for verifying that Rich on some real hardware, not a vm. I also
forgot to mention that I don't have any problems with the full version
of the program on windows 10 with 8.6.10.

My linux version is 8.6.9

I'll see if anyone else has something to add before submitting a ticket.

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

On Friday, 17 September 2021 at 21:59:33 UTC+1, tedbr...@gmail.com wrote:

I just tried Rich's change to run more threads, and got an interesting output, don't know what xcb is, but it seems on target:

Apparently, it's an updated version of Xlib.

[xcb] Unknown request in queue while appending request
[xcb] Most likely this is a multi-threaded client and XInitThreads has
not been called
[xcb] Aborting, sorry about that.

We don't call XInitThreads(); the documentation doesn't actually say what it does, but it's probably something like initialising some locking mechanisms. Tk probably ought to call that in threaded builds (i.e., always these days) during the first call to
Tk_Init().

We probably never encountered this before because not many people use multi-threaded GUIs (it's a bit like putting two applications in one process) so it's really unusual. But definitely file a bug report.

Donal.

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

On 9/18/2021 1:11 AM, Donal K. Fellows wrote:

On Friday, 17 September 2021 at 21:59:33 UTC+1, tedbr...@gmail.com wrote:

I just tried Rich's change to run more threads, and got an interesting
output, don't know what xcb is, but it seems on target:

Apparently, it's an updated version of Xlib.

[xcb] Unknown request in queue while appending request
[xcb] Most likely this is a multi-threaded client and XInitThreads has
not been called
[xcb] Aborting, sorry about that.

We don't call XInitThreads(); the documentation doesn't actually say what it does, but it's probably something like initialising some locking mechanisms. Tk probably ought to call that in threaded builds (i.e., always these days) during the first call

to Tk_Init().

We probably never encountered this before because not many people use multi-threaded GUIs (it's a bit like putting two applications in one process) so it's really unusual. But definitely file a bug report.

Donal.

Thanks for confirming this, I will submit a ticket.

I got the idea to use Tk inside threads from the earlier discussion
entitled "tcl threads benefits" which asked:

So, what benefits of tcl threads vs separate processes?

In that discussion I was struck by this comment from Christian Werner:

-----------
2. Tcl threading extends to Tk, i.e. even stuff requiring a windowing
system can be modeled with multiple threads (at least on Windows and
X11), IMO almost a unique selling point of the Tcl/Tk combo. Moreover,
when using the container/embedding technique of Tk toplevels.
-----------

I previously had preferred processes over threads because each process
had the full component of resources, and in particular the windows
console window, which I use for debugging.

I then began to think of Tcl/Tk threads as more of a lightweight
process, since by having a separate interpreter per thread, one has the
higher level memory partitioning of processes, but w/o the overhead of a full-on process and shared memory with tsv, rather than using the more
clumsy and not very portable shared memory segments that an OS provides.

But Christian's comment really intrigued me, and that led to my "Tasks" abstraction (a wrapper-class for threads done old school).

What I've always liked about *nix processes, were how they could be used
as a sort of concurrent procedure call. The input parameters are
argc/argv (and stdin) and the [return] is output to stdout.

With a tcl proc's special "args" argument, one then has argc/argv in a
sense, as [llength $args] gives you argc. And a tcl process also has the argc/argv globals at startup.

So, I thought, why not extend this to threads and gain the other
advantages with the higher level "tcl threads", such as platform
portability and Christian's insight into Tcl/Tk's unique benefit of
threaded Tk.

When I started my project, I asked here "how does one debug threads",
since on windows, I couldn't use puts to the console from a thread (and
can't even rename puts in a thread as I discovered). I then hit on the
idea of my own windows like console, which under the hood is just a text
widget running in a separate interpreter. Also, one can get color text
by using [console eval] which is especially handy for debugging, when
one's (old) eyes are getting tired looking at all that puts output.

Anyway, the result was that I implemented a [putz] call which by doing a [package require Tk] opens the . toplevel where I create a text widget,
and thus have my puts console-like debugging.

I work mostly on windows, but when I create something I intend to share
on the wiki, I always test on linux as well, and ran into this crash.
And I'm just hijacking my own post, and was getting ready to make an announcement of Tcl Tasks until I got bit by this bug.

Sorry for the long winded explanation and so I will end with this link:

https://wiki.tcl-lang.org/page/Tasks

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

Donal K. Fellows schrieb am Samstag, 18. September 2021 um 10:11:26 UTC+2:

We don't call XInitThreads(); the documentation doesn't actually say what it does, but it's probably something like initialising some locking mechanisms. Tk probably ought to call that in threaded builds (i.e., always these days) during the first call

to Tk_Init().

We probably never encountered this before because not many people use multi-threaded GUIs (it's a bit like putting two applications in one process) so it's really unusual. But definitely file a bug report.

As far as I understand the XInitThreads() man page on a Debian 10 box the purpose of it is to support an interlock of a display connection when it is used by more than one thread. However, Tcl's apartment threading model uses separate display connections
for distinct threads. Although a display connection will be shared by more than one interps in the same thread, which have Tk loaded, but those are sequential by design.

Christian

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

On 9/18/2021 1:11 AM, Donal K. Fellows wrote:

But definitely file a bug report.

I submitted one, and then I narrowed it down even more to the most
simple of all

Since I've already filed a ticket, is there a way to add an entry or
make a change to an already existing ticket?



package require Thread

set script {
package require Tk
thread::wait
}
proc wait { ms } {
after $ms set ::__sleep__tmp 1
vwait ::__sleep__tmp
}
for {set n 0} {$n < 5 } {incr n} {
thread::create $script
}

after 20000 exit
wait 2500
puts donex4a
exit

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

tedbr... schrieb am Sonntag, 19. September 2021 um 04:32:14 UTC+2:

Since I've already filed a ticket, is there a way to add an entry or
make a change to an already existing ticket?
package require Thread ...

I've added this to the existing ticket, see https://core.tcl-lang.org/tk/info/8ebed330edc670d5

Additionally I've added a proof of concept patch for testing.

Christian

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

On 9/19/2021 2:41 AM, Christian Werner wrote:

tedbr... schrieb am Sonntag, 19. September 2021 um 04:32:14 UTC+2:

Since I've already filed a ticket, is there a way to add an entry or
make a change to an already existing ticket?
package require Thread ...

I've added this to the existing ticket, see https://core.tcl-lang.org/tk/info/8ebed330edc670d5

Additionally I've added a proof of concept patch for testing.

Christian

I was stumbling to add a comment while you were writing here, but I
think I got it now, I go through the edit button.

Perhaps if Scott has the interest, he might try your suggestion, as he's
likely within a few bash uparrow's from running a build, and he could
possibly add that option you mentioned at the ticket:

What about running the same test with a Tk build using --disable-xft to
narrow the problem down? To see if Xft is the culprit.

I would have to leave the patch to others much younger as well.

On the plus side, this forced me to do a workaround, since I didn't know
that puts from a thread would work on linux. Happily I can intercept the
output to the tk window and prefix a thread name and just use puts on
the text. I can even pipe the output through grep, who does use some
nice coloring.

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

Am 20.09.21 um 02:50 schrieb Scott Pitcher:

On Sunday, September 19, 2021 at 8:31:04 PM UTC+10, tedbr...@gmail.com wrote:

Perhaps if Scott has the interest, he might try your suggestion, as he's
likely within a few bash uparrow's from running a build, and he could
possibly add that option you mentioned at the ticket:

What about running the same test with a Tk build using --disable-xft to
narrow the problem down? To see if Xft is the culprit.

I rebuilt Tk 8.6.9 with the --disable-xft configure option. I ran the first script 1000 times and had these results. 10 core dumps in total.

Now where you see "Run xxx:/home/scotty/bin/catchsegv: line 11: 5667 Aborted (core dumped) "$@"" and no other information, this is a core dump due to memory corruption which the script does not capture. Except for runs #762 and #919

which I cut and pasted from the console.

If it is a "simple" race condition, then maybe helgrind can detect it?
Try rebuilding with "CFLAGS=-DPURIFY --enable-symbols" both Tcl and Tk
(the binary is incompatible to normally built extensions) and then run
it under "helgrind"

https://valgrind.org/docs/manual/hg-manual.html

Christian

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

On 9/19/2021 5:50 PM, Scott Pitcher wrote:

On Sunday, September 19, 2021 at 8:31:04 PM UTC+10, tedbr...@gmail.com wrote:

Perhaps if Scott has the interest, he might try your suggestion, as he's
likely within a few bash uparrow's from running a build, and he could
possibly add that option you mentioned at the ticket:

What about running the same test with a Tk build using --disable-xft to
narrow the problem down? To see if Xft is the culprit.

I rebuilt Tk 8.6.9 with the --disable-xft configure option. I ran the first script 1000 times and had these results. 10 core dumps in total.

Now where you see "Run xxx:/home/scotty/bin/catchsegv: line 11: 5667 Aborted (core dumped) "$@"" and no other information, this is a core dump due to memory corruption which the script does not capture. Except for runs #762 and #919

which I cut and pasted from the console.

All the core dumps appear to originate in the new thread, when Tk_Init() is called and the last call from Tk on the stack is from TkpOpenDisplay().

Thanks for helping with this. Which script are you using, the minimal
one with just the [package require Tk] or the original one? If the
simpler one, perhaps running with more threads would make it more
consistently fail. Using a VM which is running a lot slower, also seems
to make it fail much more often.

However, I am now wondering if perhaps once this simpler case could be resolved, going back to the original might find that there is actually
more than one problem. But I guess one thing at a time.

I also wonder if that XInitThreads() might be tried and if anyone knows
where it would be placed in the source code.

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

On Saturday, 18 September 2021 at 19:04:53 UTC+1, Christian Werner wrote:

As far as I understand the XInitThreads() man page on a Debian 10 box the purpose of it is to support an interlock of a display connection when it is used by more than one thread. However, Tcl's apartment threading model uses separate display

connections for distinct threads. Although a display connection will be shared by more than one interps in the same thread, which have Tk loaded, but those are sequential by design.

I did note that the documentation doesn't actually say what it does, only that it is necessary. The presence of crashes with the thread signatures described proves that it is indeed needed, and that the prior assumption (that everything is hung off the
Display structure) is wrong. We really should call it in a multi-threaded build, probably very early in Tk_Init() (guarded by once-only construct on our side) since we can't really do anything earlier.

Donal.

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

Regarding solutions for X11 and threads there are some interesting discussions:

https://slashdot.org/comments.pl?sid=50400&cid=5099000

https://stackoverflow.com/questions/6402476/multithreaded-x11-application-and-opengl

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

Regarding solutions for X11 and threads there are some interesting discussions around the place:

https://slashdot.org/comments.pl?sid=50400&cid=5099000 (part of longer conversation https://slashdot.org/story/03/01/11/0043207/why-isnt-x11-thread-safe)

https://stackoverflow.com/questions/6402476/multithreaded-x11-application-and-opengl

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

On Tuesday, September 21, 2021 at 3:48:46 AM UTC+10, tedbr...@gmail.com wrote:

All the core dumps appear to originate in the new thread, when Tk_Init() is called and the last call from Tk on the stack is from TkpOpenDisplay().

Thanks for helping with this. Which script are you using, the minimal
one with just the [package require Tk] or the original one? If the
simpler one, perhaps running with more threads would make it more consistently fail. Using a VM which is running a lot slower, also seems
to make it fail much more often.

I'm still using the original script. I won't change things just yet.

I've installed Valgrind, and I'm running from the command line not the shell script, and running from the command line I get the following error each and every time. I've pasted two consecutive runs below, there is a slight difference in the amount of
memory Valigrind reports as "definitely lost", but I think that has no bearing on the fault.

I did try Helgrind but it reports many errors. I'll have to look at it more closely.

I haven't use Valigrind before but if I'm reading this correctly, it seems that in the thread, the X11 library is allocating a block:, freeing it, and then accessing it:

scotty@officepc:~/Engineering on server1/Projects, Software/tcltk/Test scripts$ valgrind --num-callers=25 ~/bin/tclsh crash.tcl
==20764== Memcheck, a memory error detector
==20764== Copyright (C) 2002-2015, and GNU GPL'd, by Julian Seward et al. ==20764== Using Valgrind-3.11.0 and LibVEX; rerun with -h for copyright info ==20764== Command: /home/scotty/bin/tclsh crash.tcl
==20764==
==20764== Thread 3:
==20764== Invalid read of size 1
==20764== at 0x4C31F93: strcmp (vg_replace_strmem.c:842)
==20764== by 0x9902F23: _XimUnRegisterIMInstantiateCallback (imInsClbk.c:238)
==20764== by 0x98E9EF2: XUnregisterIMInstantiateCallback (IMWrap.c:200) ==20764== by 0x8E2941C: InstantiateIMCallback (tkUnixEvent.c:681)
==20764== by 0x9902E04: _XimRegisterIMInstantiateCallback (imInsClbk.c:209) ==20764== by 0x98E9E8B: XRegisterIMInstantiateCallback (IMWrap.c:177) ==20764== by 0x8E28AB0: TkpOpenDisplay (tkUnixEvent.c:184)
==20764== by 0x8D4E897: GetScreen (tkWindow.c:465)
==20764== by 0x8D4E634: CreateTopLevelWindow (tkWindow.c:348)
==20764== by 0x8D4F3A6: TkCreateMainWindow (tkWindow.c:854)
==20764== by 0x8D5F1D7: CreateFrame (tkFrame.c:582)
==20764== by 0x8D5ECB7: TkListCreateFrame (tkFrame.c:468)
==20764== by 0x8D53014: Initialize (tkWindow.c:3254)
==20764== by 0x8D521A2: Tk_Init (tkWindow.c:2914)
==20764== by 0x4FBDE34: Tcl_LoadObjCmd (tclLoad.c:464)
==20764== by 0x4E840B1: Dispatch (tclBasic.c:4426)
==20764== by 0x4E8413E: TclNRRunCallbacks (tclBasic.c:4461)
==20764== by 0x4E8396B: Tcl_EvalObjv (tclBasic.c:4189)
==20764== by 0x4E85F3A: TclEvalEx (tclBasic.c:5330)
==20764== by 0x4E85268: Tcl_EvalEx (tclBasic.c:4995)
==20764== by 0x76B7C2F: NewThread (threadCmd.c:1858)
==20764== by 0x4F557B2: NewThreadProc (tclEvent.c:1568)
==20764== by 0x5A7D6B9: start_thread (pthread_create.c:333)
==20764== Address 0xa7e8ea0 is 0 bytes inside a block of size 1 free'd ==20764== at 0x4C2EDEB: free (vg_replace_malloc.c:530)
==20764== by 0x98F905C: XSetLocaleModifiers (lcWrap.c:89)
==20764== by 0x8E294BF: OpenIM (tkUnixEvent.c:725)
==20764== by 0x8E28A84: TkpOpenDisplay (tkUnixEvent.c:183)
==20764== by 0x8D4E897: GetScreen (tkWindow.c:465)
==20764== by 0x8D4E634: CreateTopLevelWindow (tkWindow.c:348)
==20764== by 0x8D4F3A6: TkCreateMainWindow (tkWindow.c:854)
==20764== by 0x8D5F1D7: CreateFrame (tkFrame.c:582)
==20764== by 0x8D5ECB7: TkListCreateFrame (tkFrame.c:468)
==20764== by 0x8D53014: Initialize (tkWindow.c:3254)
==20764== by 0x8D521A2: Tk_Init (tkWindow.c:2914)
==20764== by 0x4FBDE34: Tcl_LoadObjCmd (tclLoad.c:464)
==20764== by 0x4E840B1: Dispatch (tclBasic.c:4426)
==20764== by 0x4E8413E: TclNRRunCallbacks (tclBasic.c:4461)
==20764== by 0x4E8396B: Tcl_EvalObjv (tclBasic.c:4189)
==20764== by 0x4E85F3A: TclEvalEx (tclBasic.c:5330)
==20764== by 0x4E85268: Tcl_EvalEx (tclBasic.c:4995)
==20764== by 0x76B7C2F: NewThread (threadCmd.c:1858)
==20764== by 0x4F557B2: NewThreadProc (tclEvent.c:1568)
==20764== by 0x5A7D6B9: start_thread (pthread_create.c:333)
==20764== Block was alloc'd at
==20764== at 0x4C2DB8F: malloc (vg_replace_malloc.c:299)
==20764== by 0x98F8C77: _XlcDefaultMapModifiers (lcWrap.c:146)
==20764== by 0x98F9045: XSetLocaleModifiers (lcWrap.c:87)
==20764== by 0x8E294BF: OpenIM (tkUnixEvent.c:725)
==20764== by 0x8E28A84: TkpOpenDisplay (tkUnixEvent.c:183)
==20764== by 0x8D4E897: GetScreen (tkWindow.c:465)
==20764== by 0x8D4E634: CreateTopLevelWindow (tkWindow.c:348)
==20764== by 0x8D4F3A6: TkCreateMainWindow (tkWindow.c:854)
==20764== by 0x8D5F1D7: CreateFrame (tkFrame.c:582)
==20764== by 0x8D5ECB7: TkListCreateFrame (tkFrame.c:468)
==20764== by 0x8D53014: Initialize (tkWindow.c:3254)
==20764== by 0x8D521A2: Tk_Init (tkWindow.c:2914)
==20764== by 0x4FBDE34: Tcl_LoadObjCmd (tclLoad.c:464)
==20764== by 0x4E840B1: Dispatch (tclBasic.c:4426)
==20764== by 0x4E8413E: TclNRRunCallbacks (tclBasic.c:4461)
==20764== by 0x4E8396B: Tcl_EvalObjv (tclBasic.c:4189)
==20764== by 0x4E85F3A: TclEvalEx (tclBasic.c:5330)
==20764== by 0x4E85268: Tcl_EvalEx (tclBasic.c:4995)
==20764== by 0x76B7C2F: NewThread (threadCmd.c:1858)
==20764== by 0x4F557B2: NewThreadProc (tclEvent.c:1568)
==20764== by 0x5A7D6B9: start_thread (pthread_create.c:333)
==20764==
done
==20764==
==20764== HEAP SUMMARY:
==20764== in use at exit: 6,205,834 bytes in 27,707 blocks
==20764== total heap usage: 225,668 allocs, 197,961 frees, 37,953,711 bytes allocated
==20764==
==20764== LEAK SUMMARY:
==20764== definitely lost: 816 bytes in 2 blocks
==20764== indirectly lost: 0 bytes in 0 blocks
==20764== possibly lost: 816 bytes in 3 blocks
==20764== still reachable: 6,204,202 bytes in 27,702 blocks
==20764== suppressed: 0 bytes in 0 blocks
==20764== Rerun with --leak-check=full to see details of leaked memory ==20764==
==20764== For counts of detected and suppressed errors, rerun with: -v ==20764== ERROR SUMMARY: 3 errors from 1 contexts (suppressed: 0 from 0) scotty@officepc:~/Engineering on server1/Projects, Software/tcltk/Test scripts$


scotty@officepc:~/Engineering on server1/Projects, Software/tcltk/Test scripts$ valgrind --num-callers=25 ~/bin/tclsh crash.tcl
==23167== Memcheck, a memory error detector
==23167== Copyright (C) 2002-2015, and GNU GPL'd, by Julian Seward et al. ==23167== Using Valgrind-3.11.0 and LibVEX; rerun with -h for copyright info ==23167== Command: /home/scotty/bin/tclsh crash.tcl
==23167==
==23167== Thread 2:
==23167== Invalid read of size 1
==23167== at 0x4C31F93: strcmp (vg_replace_strmem.c:842)
==23167== by 0xA903F23: _XimUnRegisterIMInstantiateCallback (imInsClbk.c:238)
==23167== by 0xA8EAEF2: XUnregisterIMInstantiateCallback (IMWrap.c:200) ==23167== by 0xA62B41C: InstantiateIMCallback (tkUnixEvent.c:681)
==23167== by 0xA903E04: _XimRegisterIMInstantiateCallback (imInsClbk.c:209) ==23167== by 0xA8EAE8B: XRegisterIMInstantiateCallback (IMWrap.c:177) ==23167== by 0xA62AAB0: TkpOpenDisplay (tkUnixEvent.c:184)
==23167== by 0xA550897: GetScreen (tkWindow.c:465)
==23167== by 0xA550634: CreateTopLevelWindow (tkWindow.c:348)
==23167== by 0xA5513A6: TkCreateMainWindow (tkWindow.c:854)
==23167== by 0xA5611D7: CreateFrame (tkFrame.c:582)
==23167== by 0xA560CB7: TkListCreateFrame (tkFrame.c:468)
==23167== by 0xA555014: Initialize (tkWindow.c:3254)
==23167== by 0xA5541A2: Tk_Init (tkWindow.c:2914)
==23167== by 0x4FBDE34: Tcl_LoadObjCmd (tclLoad.c:464)
==23167== by 0x4E840B1: Dispatch (tclBasic.c:4426)
==23167== by 0x4E8413E: TclNRRunCallbacks (tclBasic.c:4461)
==23167== by 0x4E8396B: Tcl_EvalObjv (tclBasic.c:4189)
==23167== by 0x4E85F3A: TclEvalEx (tclBasic.c:5330)
==23167== by 0x4E85268: Tcl_EvalEx (tclBasic.c:4995)
==23167== by 0x76B7C2F: NewThread (threadCmd.c:1858)
==23167== by 0x4F557B2: NewThreadProc (tclEvent.c:1568)
==23167== by 0x5A7D6B9: start_thread (pthread_create.c:333)
==23167== Address 0x9cbdd70 is 0 bytes inside a block of size 1 free'd ==23167== at 0x4C2EDEB: free (vg_replace_malloc.c:530)
==23167== by 0xA8FA05C: XSetLocaleModifiers (lcWrap.c:89)
==23167== by 0xA62B4BF: OpenIM (tkUnixEvent.c:725)
==23167== by 0xA62B3F0: InstantiateIMCallback (tkUnixEvent.c:680)
==23167== by 0xA903E04: _XimRegisterIMInstantiateCallback (imInsClbk.c:209) ==23167== by 0xA8EAE8B: XRegisterIMInstantiateCallback (IMWrap.c:177) ==23167== by 0xA62AAB0: TkpOpenDisplay (tkUnixEvent.c:184)
==23167== by 0xA550897: GetScreen (tkWindow.c:465)
==23167== by 0xA550634: CreateTopLevelWindow (tkWindow.c:348)
==23167== by 0xA5513A6: TkCreateMainWindow (tkWindow.c:854)
==23167== by 0xA5611D7: CreateFrame (tkFrame.c:582)
==23167== by 0xA560CB7: TkListCreateFrame (tkFrame.c:468)
==23167== by 0xA555014: Initialize (tkWindow.c:3254)
==23167== by 0xA5541A2: Tk_Init (tkWindow.c:2914)
==23167== by 0x4FBDE34: Tcl_LoadObjCmd (tclLoad.c:464)
==23167== by 0x4E840B1: Dispatch (tclBasic.c:4426)
==23167== by 0x4E8413E: TclNRRunCallbacks (tclBasic.c:4461)
==23167== by 0x4E8396B: Tcl_EvalObjv (tclBasic.c:4189)
==23167== by 0x4E85F3A: TclEvalEx (tclBasic.c:5330)
==23167== by 0x4E85268: Tcl_EvalEx (tclBasic.c:4995)
==23167== by 0x76B7C2F: NewThread (threadCmd.c:1858)
==23167== by 0x4F557B2: NewThreadProc (tclEvent.c:1568)
==23167== by 0x5A7D6B9: start_thread (pthread_create.c:333)
==23167== Block was alloc'd at
==23167== at 0x4C2DB8F: malloc (vg_replace_malloc.c:299)
==23167== by 0xA8F9C77: _XlcDefaultMapModifiers (lcWrap.c:146)
==23167== by 0xA8FA045: XSetLocaleModifiers (lcWrap.c:87)
==23167== by 0xA62B4BF: OpenIM (tkUnixEvent.c:725)
==23167== by 0xA62AA84: TkpOpenDisplay (tkUnixEvent.c:183)
==23167== by 0xA550897: GetScreen (tkWindow.c:465)
==23167== by 0xA550634: CreateTopLevelWindow (tkWindow.c:348)
==23167== by 0xA5513A6: TkCreateMainWindow (tkWindow.c:854)
==23167== by 0xA5611D7: CreateFrame (tkFrame.c:582)
==23167== by 0xA560CB7: TkListCreateFrame (tkFrame.c:468)
==23167== by 0xA555014: Initialize (tkWindow.c:3254)
==23167== by 0xA5541A2: Tk_Init (tkWindow.c:2914)
==23167== by 0x4FBDE34: Tcl_LoadObjCmd (tclLoad.c:464)
==23167== by 0x4E840B1: Dispatch (tclBasic.c:4426)
==23167== by 0x4E8413E: TclNRRunCallbacks (tclBasic.c:4461)
==23167== by 0x4E8396B: Tcl_EvalObjv (tclBasic.c:4189)
==23167== by 0x4E85F3A: TclEvalEx (tclBasic.c:5330)
==23167== by 0x4E85268: Tcl_EvalEx (tclBasic.c:4995)
==23167== by 0x76B7C2F: NewThread (threadCmd.c:1858)
==23167== by 0x4F557B2: NewThreadProc (tclEvent.c:1568)
==23167== by 0x5A7D6B9: start_thread (pthread_create.c:333)
==23167==
done
==23167==
==23167== HEAP SUMMARY:
==23167== in use at exit: 6,705,219 bytes in 34,323 blocks
==23167== total heap usage: 230,006 allocs, 195,683 frees, 37,377,289 bytes allocated
==23167==
==23167== LEAK SUMMARY:
==23167== definitely lost: 408 bytes in 1 blocks
==23167== indirectly lost: 0 bytes in 0 blocks
==23167== possibly lost: 816 bytes in 3 blocks
==23167== still reachable: 6,703,995 bytes in 34,319 blocks
==23167== suppressed: 0 bytes in 0 blocks
==23167== Rerun with --leak-check=full to see details of leaked memory ==23167==
==23167== For counts of detected and suppressed errors, rerun with: -v ==23167== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 0 from 0) scotty@officepc:~/Engineering on server1/Projects, Software/tcltk/Test scripts$

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

Le 22/09/2021 à 14:32, Scott Pitcher a écrit :

==20764== Invalid read of size 1
==20764== at 0x4C31F93: strcmp (vg_replace_strmem.c:842)
==20764== by 0x9902F23: _XimUnRegisterIMInstantiateCallback (imInsClbk.c:238)
==20764== by 0x98E9EF2: XUnregisterIMInstantiateCallback (IMWrap.c:200) ==20764== by 0x8E2941C: InstantiateIMCallback (tkUnixEvent.c:681) ==20764== by 0x9902E04: _XimRegisterIMInstantiateCallback (imInsClbk.c:209)

This is known, and fixed in libX11:

https://core.tcl-lang.org/tk/tktview?name=e42eef33ee

Regards,
Francois

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

On Thursday, September 23, 2021 at 12:02:29 AM UTC+10, Francois Vogel wrote:

Le 22/09/2021 à 14:32, Scott Pitcher a écrit :

This is known, and fixed in libX11:

Ah, thank you Francois. And it looks like my Ubuntu is running 1.6.3, while the fix will come through in 1.7.0.

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