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'm running on a virtual pop-os (ubuntu) and the below script will
crash tclsh every so often but not every time.
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.
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:
[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.
On Friday, 17 September 2021 at 21:59:33 UTC+1, tedbr...@gmail.com wrote:to Tk_Init().
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
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.
So, what benefits of tcl threads vs separate processes?
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 callto 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.
But definitely file a bug report.
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 ...
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
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.
On Sunday, September 19, 2021 at 8:31:04 PM UTC+10, tedbr...@gmail.com wrote:which I cut and pasted from the console.
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
On Sunday, September 19, 2021 at 8:31:04 PM UTC+10, tedbr...@gmail.com wrote:which I cut and pasted from the console.
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
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().
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 displayconnections 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.
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.
==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)
Le 22/09/2021 à 14:32, Scott Pitcher a écrit :
This is known, and fixed in libX11:
Sysop: | Keyop |
---|---|
Location: | Huddersfield, West Yorkshire, UK |
Users: | 285 |
Nodes: | 16 (2 / 14) |
Uptime: | 32:51:38 |
Calls: | 6,449 |
Calls today: | 1 |
Files: | 12,052 |
Messages: | 5,254,898 |