Minimal example:
package require Thread
set thread_script {
package require Iwidgets
iwidgets::pushbutton .btn -text [thread::id]
pack .btn
after 4000 [list thread::release [thread::id]]
thread::wait
}
for {set i 0} {$i<1000} {incr i} {
thread::create -preserved $thread_script
after 500
}
This code runs 8 threads in parallel each showing an iwidget (pushbutton
or anything else, doesn't matter) and after ~1 minute it crashes with:
Unhandled exception at 0x00007FF8846DA6E4 (itcl424t.dll) in
tclsh86t.exe: 0xC0000005: Access violation reading location 0x0000000000000018.
Windows, Tcl 8.6.14, Itcl 4.2.4, Itk 4.2.6, Iwidgets 4.1.
The same crash happens when using the Itk written in pure Tcl: https://chiselapp.com/user/rene/repository/itk/home
That's why I'm convinced the problem is in Itcl rather than Itk, and the stack trace points to Itcl as well. Probably, there is a mutex missing somewhere.
I didn't try to reproduce it on Linux.
I understand that both Iwidgets and Itcl are legacy that is barely maintained, that's why I'm not raising a bug in Fossil that very few
people would notice. What I'm asking instead from a much wider audience
here is for a workaround. Is it possible to change my code somehow to
avoid the crash? Of course, preserving the basic multi-threaded architecture.
The original code is a huge framework that can't be rewritten to
separate GUI into one main thread.
Thanks in advance,
Petro
Am 23.08.2024 um 14:29 schrieb Petro Kazmirchuk:
Minimal example:
package require Thread
set thread_script {
package require Iwidgets
iwidgets::pushbutton .btn -text [thread::id]
pack .btn
after 4000 [list thread::release [thread::id]]
thread::wait
}
for {set i 0} {$i<1000} {incr i} {
thread::create -preserved $thread_script
after 500
}
This code runs 8 threads in parallel each showing an iwidget
(pushbutton or anything else, doesn't matter) and after ~1 minute it
crashes with:
Unhandled exception at 0x00007FF8846DA6E4 (itcl424t.dll) in
tclsh86t.exe: 0xC0000005: Access violation reading location
0x0000000000000018.
Windows, Tcl 8.6.14, Itcl 4.2.4, Itk 4.2.6, Iwidgets 4.1.
The same crash happens when using the Itk written in pure Tcl:
https://chiselapp.com/user/rene/repository/itk/home
That's why I'm convinced the problem is in Itcl rather than Itk, and
the stack trace points to Itcl as well. Probably, there is a mutex
missing somewhere.
I didn't try to reproduce it on Linux.
I understand that both Iwidgets and Itcl are legacy that is barely
maintained, that's why I'm not raising a bug in Fossil that very few
people would notice. What I'm asking instead from a much wider
audience here is for a workaround. Is it possible to change my code
somehow to avoid the crash? Of course, preserving the basic
multi-threaded architecture.
The original code is a huge framework that can't be rewritten to
separate GUI into one main thread.
Thanks in advance,
Petro
Petro,
if you look here: https://core.tcl-lang.org/itcl/timeline?udc=1&ss=v&n=&y=all&advm=0
ITCL has commits two days ago. So, there is some care.
It is a bundled package.
So it would be great to file a bug report.
Thanks,
Harald
This code runs 8 threads in parallel each showing an iwidget (pushbutton
or anything else, doesn't matter) and after ~1 minute it crashes with:
Unhandled exception at 0x00007FF8846DA6E4 (itcl424t.dll) in
tclsh86t.exe: 0xC0000005: Access violation reading location 0x0000000000000018.
...
That's why I'm convinced the problem is in Itcl rather than Itk, and the stack trace points to Itcl as well. Probably, there is a mutex missing somewhere.
I didn't try to reproduce it on Linux.
I understand that both Iwidgets and Itcl are legacy that is barely maintained, that's why I'm not raising a bug in Fossil that very few
people would notice. What I'm asking instead from a much wider audience
here is for a workaround. Is it possible to change my code somehow to
avoid the crash? Of course, preserving the basic multi-threaded architecture.
...
The original code is a huge framework that can't be rewritten to
separate GUI into one main thread.
Sysop: | DaiTengu |
---|---|
Location: | Appleton, WI |
Users: | 991 |
Nodes: | 10 (0 / 10) |
Uptime: | 119:54:48 |
Calls: | 12,958 |
Files: | 186,574 |
Messages: | 3,265,641 |