Menu
▾
▴
tcl-core
|
From: <apn...@ya...> - 2024-07-26 13:38:31
|
Summary: ignoring usual test noise (file perms on Windows, tdbc drivers) the
following failures seen.
- tktest90 crash on exit on Windows 10 x64 (Visual Studio 2022 17.9)
- 2 zlib failures on Linux and a scary compile warning
Windows
Tcl and package tests pass except for lack of tdbc drivers
Tk - shows usual "Clipboard busy errors".
More important, tktest90 crashes on exit (I think). Narrowed it down to
winClipboard.test (or at least this file by itself triggers the crash unlike
other test files). Anyone testing will likely need to enable the JIT
debugger on Windows else you will not notice the crash as it happens while
exiting. Alternatively, check the Windows Application log where the crash is
reported. My VS Studio debugger reports it cannot determine crash location
because the unhandled exception is .NET 4.0 and the debugger only supports
2.0. I don't even know where .NET enters the picture (does Tk use any UI
features from .NET) ?
Linux (Tcl only, do not have a X server)
On my WSL installation, all tests pass.
On Stefan's system, 2 zlib failures seen along with a compiler warning.
My WSL: Linux IO 5.15.153.1-microsoft-standard-WSL2 #1 SMP Fri Mar 29
23:14:13 UTC 2024 x86_64 x86_64 x86_64 GNU/Linux
Stefan's system: Linux tcltk.wu.ac.at 6.9.9-200.fc40.x86_64 #1 SMP
PREEMPT_DYNAMIC Thu Jul 11 19:29:01 UTC 2024 x86_64 GNU/Linux
==== zlib-8.8 transformation and fconfigure FAILED
==== Contents of test case:
zlib push compress $outSide -dictionary $spdyDict
fconfigure $outSide -blocking 1 -translation binary -buffering none
fconfigure $inSide -blocking 1 -translation binary
puts -nonewline $outSide $spdyHeaders
chan pop $outSide
chan close $outSide
set compressed [read $inSide]
catch {zlib decompress $compressed} err opt
list [string length [zlib compress $spdyHeaders]] [string length
$compressed] $err [dict get $opt -errorcode] [zlib adler32 $spdyDict]
---- Result was:
261 227 {need dictionary} {TCL ZLIB NEED_DICT 2381337010} 2381337010
---- Result should have been (exact matching):
260 222 {need dictionary} {TCL ZLIB NEED_DICT 2381337010} 2381337010
==== zlib-8.8 FAILED
==== zlib-8.16 Bug 3603553: buffer transfer with large writes FAILED
==== Contents of test case:
set f [open $file wb]
fconfigure $f -buffering none
zlib push gzip $f
puts -nonewline $f $largeData
close $f
file size $file
---- Result was:
54408
---- Result should have been (exact matching):
57647
==== zlib-8.16 FAILED
Additionally during compile the following warning is seen:
/home/apn/src/tcl9.0b3/unix/tclUnixPipe.c: In function 'TclpCreateProcess':
/home/apn/src/tcl9.0b3/unix/tclUnixPipe.c:431:18: warning: variable
'dsArray' might be clobbered by 'longjmp' or 'vfork' [-Wclobbered]
431 | Tcl_DString *dsArray;
| ^~~~~~~
/home/apn/src/tcl9.0b3/unix/tclUnixPipe.c:432:12: warning: variable
'newArgv' might be clobbered by 'longjmp' or 'vfork' [-Wclobbered]
432 | char **newArgv;
| ^~~~~~~
No idea why the errors show on Stefan's box but not my WSL. Perhaps gcc
version.
/Ashok
|
|
From: Harald O. <har...@el...> - 2024-07-26 13:54:04
Attachments:
OpenPGP_signature.asc
|
Ashok, great tests, I appreciate ! Am 26.07.2024 um 15:38 schrieb apnmbx-public--- via Tcl-Core: > Tk – shows usual “Clipboard busy errors”. > > More important, tktest90 crashes on exit (I think). Narrowed it down to > winClipboard.test (or at least this file by itself triggers the crash > unlike other test files). Anyone testing will likely need to enable the > JIT debugger on Windows else you will not notice the crash as it happens > while exiting. Alternatively, check the Windows Application log where > the crash is reported. My VS Studio debugger reports it cannot determine > crash location because the unhandled exception is .NET 4.0 and the > debugger only supports 2.0. I don't even know where .NET enters the > picture (does Tk use any UI features from .NET) ? I suppose, another application written in .NET4 running on your computer and holding the clipboard is crashing due to the Tk clipboard requests. Clipboard is a shared resource and specially terminal programs (UltraVNC, Windows Remote Desktop or any virtualisation software may mess this up). Also, I have seen that in Windows 11, there is an extension to get an extended cliboard with a history list. I can reproduce the "usual Clipboard busy errors" with UltraVNC. It you have "Windows Remote Desktop" active, there is an option when setting it up: press Options on the first connection screen, then choose "local resources", then Keyboard. Choose "on this computer" there. Also uncheck the clipboard checkbox. Just arbitrary guesses and eventually only noise but anyway, Harald |
|
From: <apn...@ya...> - 2024-07-26 15:10:29
|
Add volatile just before the identifier, right? That seems to have fixed the warnings.
From: Gustaf Neumann (sslmail) <ne...@wu...>
Sent: Friday, July 26, 2024 8:22 PM
To: apn...@ya...
Subject: Re: [TCLCORE] 9.0b3rc0 test results / bugs
Hi Ashok, Can you try to add "volatile” in front of these two declarations?
Additionally during compile the following warning is seen:
/home/apn/src/tcl9.0b3/unix/tclUnixPipe.c: In function ‘TclpCreateProcess’:
/home/apn/src/tcl9.0b3/unix/tclUnixPipe.c:431:18: warning: variable ‘dsArray’ might be clobbered by ‘longjmp’ or ‘vfork’ [-Wclobbered]
431 | Tcl_DString *dsArray;
| ^~~~~~~
/home/apn/src/tcl9.0b3/unix/tclUnixPipe.c:432:12: warning: variable ‘newArgv’ might be clobbered by ‘longjmp’ or ‘vfork’ [-Wclobbered]
432 | char **newArgv;
| ^~~~~~~
No idea why the errors show on Stefan’s box but not my WSL. Perhaps gcc version.
/Ashok
|
|
From: Francois V. <fvo...@fr...> - 2024-07-26 17:22:21
|
This is reported for each and every release candidate. It's the following ticket: https://core.tcl-lang.org/tk/tktview/ee397e0a55 Jan has set it to Pending+Fixed but it isn't fixed as you noticed once more, and I'm wondering it's pending what. Since we stepped on each other's toes with Jan on this ticket (see discussion there), I have abandoned solving this almost one year ago. Regards, Francois Le 26/07/2024 à 15:53, Harald Oehlmann a écrit : > Ashok, > great tests, I appreciate ! > > Am 26.07.2024 um 15:38 schrieb apnmbx-public--- via Tcl-Core: >> Tk – shows usual “Clipboard busy errors”. >> >> More important, tktest90 crashes on exit (I think). Narrowed it down >> to winClipboard.test (or at least this file by itself triggers the >> crash unlike other test files). Anyone testing will likely need to >> enable the JIT debugger on Windows else you will not notice the crash >> as it happens while exiting. Alternatively, check the Windows >> Application log where the crash is reported. My VS Studio debugger >> reports it cannot determine crash location because the unhandled >> exception is .NET 4.0 and the debugger only supports 2.0. I don't >> even know where .NET enters the picture (does Tk use any UI features >> from .NET) ? > > I suppose, another application written in .NET4 running on your > computer and holding the clipboard is crashing due to the Tk clipboard > requests. > > Clipboard is a shared resource and specially terminal programs > (UltraVNC, Windows Remote Desktop or any virtualisation software may > mess this up). Also, I have seen that in Windows 11, there is an > extension to get an extended cliboard with a history list. > > I can reproduce the "usual Clipboard busy errors" with UltraVNC. > It you have "Windows Remote Desktop" active, there is an option when > setting it up: press Options on the first connection screen, then > choose "local resources", then Keyboard. Choose "on this computer" > there. Also uncheck the clipboard checkbox. > > Just arbitrary guesses and eventually only noise but anyway, > Harald > > > > _______________________________________________ > Tcl-Core mailing list > Tcl...@li... > https://lists.sourceforge.net/lists/listinfo/tcl-core |
|
From: Jan N. <jan...@gm...> - 2024-07-26 18:35:19
|
Op vr 26 jul 2024 11:22 schreef Francois Vogel <fvo...@fr...>: > This is reported for each and every release candidate. It's the > following ticket: > > https://core.tcl-lang.org/tk/tktview/ee397e0a55 > > Jan has set it to Pending+Fixed but it isn't fixed as you noticed once > more, and I'm wondering it's pending what. > It's proposed fix is in the "bug-ee397e0a55" branch, but it appears to be incomplete. Hope this helps Jan Nijtmans |
|
From: Harald O. <har...@el...> - 2024-07-26 17:27:19
Attachments:
OpenPGP_signature.asc
|
Francois, thank for bringing this into our attention and sorry for the annoying situation. The ticket you mentioned is indeed fixed for me (but not for Ashok). But this ticket is new and Ashok fixed it with light speed. Please look to the description here: https://core.tcl-lang.org/tk/info/d233f01e2a8b3b68 including the IMHO great fix. Thanks for all your work ! Harald Am 26.07.2024 um 19:22 schrieb Francois Vogel: > This is reported for each and every release candidate. It's the > following ticket: > > https://core.tcl-lang.org/tk/tktview/ee397e0a55 > > Jan has set it to Pending+Fixed but it isn't fixed as you noticed once > more, and I'm wondering it's pending what. > > Since we stepped on each other's toes with Jan on this ticket (see > discussion there), I have abandoned solving this almost one year ago. > > Regards, > > Francois > > Le 26/07/2024 à 15:53, Harald Oehlmann a écrit : >> Ashok, >> great tests, I appreciate ! >> >> Am 26.07.2024 um 15:38 schrieb apnmbx-public--- via Tcl-Core: >>> Tk – shows usual “Clipboard busy errors”. >>> >>> More important, tktest90 crashes on exit (I think). Narrowed it down >>> to winClipboard.test (or at least this file by itself triggers the >>> crash unlike other test files). Anyone testing will likely need to >>> enable the JIT debugger on Windows else you will not notice the crash >>> as it happens while exiting. Alternatively, check the Windows >>> Application log where the crash is reported. My VS Studio debugger >>> reports it cannot determine crash location because the unhandled >>> exception is .NET 4.0 and the debugger only supports 2.0. I don't >>> even know where .NET enters the picture (does Tk use any UI features >>> from .NET) ? >> >> I suppose, another application written in .NET4 running on your >> computer and holding the clipboard is crashing due to the Tk clipboard >> requests. >> >> Clipboard is a shared resource and specially terminal programs >> (UltraVNC, Windows Remote Desktop or any virtualisation software may >> mess this up). Also, I have seen that in Windows 11, there is an >> extension to get an extended cliboard with a history list. >> >> I can reproduce the "usual Clipboard busy errors" with UltraVNC. >> It you have "Windows Remote Desktop" active, there is an option when >> setting it up: press Options on the first connection screen, then >> choose "local resources", then Keyboard. Choose "on this computer" >> there. Also uncheck the clipboard checkbox. >> >> Just arbitrary guesses and eventually only noise but anyway, >> Harald |
|
From: Francois V. <fvo...@fr...> - 2024-07-26 17:36:02
|
There are two different topics. What Ashok fixed is a crash on exit. Nice and fine. What I wanted to answer to is the "Tk – shows usual “Clipboard busy errors”." mention that starts Ashok's message. Not fixed for anybody. Regards, Francois Le 26/07/2024 à 19:26, Harald Oehlmann a écrit : > Francois, > thank for bringing this into our attention and sorry for the annoying > situation. The ticket you mentioned is indeed fixed for me (but not > for Ashok). > > But this ticket is new and Ashok fixed it with light speed. Please > look to the description here: > https://core.tcl-lang.org/tk/info/d233f01e2a8b3b68 > including the IMHO great fix. > > Thanks for all your work ! > Harald > > > Am 26.07.2024 um 19:22 schrieb Francois Vogel: >> This is reported for each and every release candidate. It's the >> following ticket: >> >> https://core.tcl-lang.org/tk/tktview/ee397e0a55 >> >> Jan has set it to Pending+Fixed but it isn't fixed as you noticed >> once more, and I'm wondering it's pending what. >> >> Since we stepped on each other's toes with Jan on this ticket (see >> discussion there), I have abandoned solving this almost one year ago. >> >> Regards, >> >> Francois >> >> Le 26/07/2024 à 15:53, Harald Oehlmann a écrit : >>> Ashok, >>> great tests, I appreciate ! >>> >>> Am 26.07.2024 um 15:38 schrieb apnmbx-public--- via Tcl-Core: >>>> Tk – shows usual “Clipboard busy errors”. >>>> >>>> More important, tktest90 crashes on exit (I think). Narrowed it >>>> down to winClipboard.test (or at least this file by itself triggers >>>> the crash unlike other test files). Anyone testing will likely need >>>> to enable the JIT debugger on Windows else you will not notice the >>>> crash as it happens while exiting. Alternatively, check the Windows >>>> Application log where the crash is reported. My VS Studio debugger >>>> reports it cannot determine crash location because the unhandled >>>> exception is .NET 4.0 and the debugger only supports 2.0. I don't >>>> even know where .NET enters the picture (does Tk use any UI >>>> features from .NET) ? >>> >>> I suppose, another application written in .NET4 running on your >>> computer and holding the clipboard is crashing due to the Tk >>> clipboard requests. >>> >>> Clipboard is a shared resource and specially terminal programs >>> (UltraVNC, Windows Remote Desktop or any virtualisation software may >>> mess this up). Also, I have seen that in Windows 11, there is an >>> extension to get an extended cliboard with a history list. >>> >>> I can reproduce the "usual Clipboard busy errors" with UltraVNC. >>> It you have "Windows Remote Desktop" active, there is an option when >>> setting it up: press Options on the first connection screen, then >>> choose "local resources", then Keyboard. Choose "on this computer" >>> there. Also uncheck the clipboard checkbox. >>> >>> Just arbitrary guesses and eventually only noise but anyway, >>> Harald > > > > _______________________________________________ > Tcl-Core mailing list > Tcl...@li... > https://lists.sourceforge.net/lists/listinfo/tcl-core |
|
From: <apn...@ya...> - 2024-07-26 15:03:16
|
Logged ticket and proposed fix for the tktest/wish crash on exit. https://core.tcl-lang.org/tk/tktview/d233f01e2a Someone please review. /Ashok From: apnmbx-public--- via Tcl-Core <tcl...@li...> Sent: Friday, July 26, 2024 7:08 PM To: tcl...@li... Subject: [TCLCORE] 9.0b3rc0 test results / bugs Summary: ignoring usual test noise (file perms on Windows, tdbc drivers) the following failures seen. - tktest90 crash on exit on Windows 10 x64 (Visual Studio 2022 17.9) - 2 zlib failures on Linux and a scary compile warning Windows Tcl and package tests pass except for lack of tdbc drivers Tk - shows usual "Clipboard busy errors". More important, tktest90 crashes on exit (I think). Narrowed it down to winClipboard.test (or at least this file by itself triggers the crash unlike other test files). Anyone testing will likely need to enable the JIT debugger on Windows else you will not notice the crash as it happens while exiting. Alternatively, check the Windows Application log where the crash is reported. My VS Studio debugger reports it cannot determine crash location because the unhandled exception is .NET 4.0 and the debugger only supports 2.0. I don't even know where .NET enters the picture (does Tk use any UI features from .NET) ? Linux (Tcl only, do not have a X server) On my WSL installation, all tests pass. On Stefan's system, 2 zlib failures seen along with a compiler warning. My WSL: Linux IO 5.15.153.1-microsoft-standard-WSL2 #1 SMP Fri Mar 29 23:14:13 UTC 2024 x86_64 x86_64 x86_64 GNU/Linux Stefan's system: Linux tcltk.wu.ac.at 6.9.9-200.fc40.x86_64 #1 SMP PREEMPT_DYNAMIC Thu Jul 11 19:29:01 UTC 2024 x86_64 GNU/Linux ==== zlib-8.8 transformation and fconfigure FAILED ==== Contents of test case: zlib push compress $outSide -dictionary $spdyDict fconfigure $outSide -blocking 1 -translation binary -buffering none fconfigure $inSide -blocking 1 -translation binary puts -nonewline $outSide $spdyHeaders chan pop $outSide chan close $outSide set compressed [read $inSide] catch {zlib decompress $compressed} err opt list [string length [zlib compress $spdyHeaders]] [string length $compressed] $err [dict get $opt -errorcode] [zlib adler32 $spdyDict] ---- Result was: 261 227 {need dictionary} {TCL ZLIB NEED_DICT 2381337010} 2381337010 ---- Result should have been (exact matching): 260 222 {need dictionary} {TCL ZLIB NEED_DICT 2381337010} 2381337010 ==== zlib-8.8 FAILED ==== zlib-8.16 Bug 3603553: buffer transfer with large writes FAILED ==== Contents of test case: set f [open $file wb] fconfigure $f -buffering none zlib push gzip $f puts -nonewline $f $largeData close $f file size $file ---- Result was: 54408 ---- Result should have been (exact matching): 57647 ==== zlib-8.16 FAILED Additionally during compile the following warning is seen: /home/apn/src/tcl9.0b3/unix/tclUnixPipe.c: In function 'TclpCreateProcess': /home/apn/src/tcl9.0b3/unix/tclUnixPipe.c:431:18: warning: variable 'dsArray' might be clobbered by 'longjmp' or 'vfork' [-Wclobbered] 431 | Tcl_DString *dsArray; | ^~~~~~~ /home/apn/src/tcl9.0b3/unix/tclUnixPipe.c:432:12: warning: variable 'newArgv' might be clobbered by 'longjmp' or 'vfork' [-Wclobbered] 432 | char **newArgv; | ^~~~~~~ No idea why the errors show on Stefan's box but not my WSL. Perhaps gcc version. /Ashok |
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X