Skip Menu |

This queue is for tickets about the Tcl-pTk CPAN distribution.

Report information
The Basics
Id: 128804
Status: patched
Priority: 0/
Queue: Tcl-pTk

Owner: CAC [...]
Requestors: SREZIC [...]

Bug Information
Severity: (no value)
Broken in: 0.96
Fixed in: (no value)

Subject: t/configureReturn.t: segmentations faults on centos 6
Download (untitled) / with headers
text/plain 298b
t/configureReturn.t fails (with an segfault) on my centos 6 smokers: ... t/configureReturn.t ........... All 20 subtests passed (less 3 skipped subtests: 17 okay) ... Test Summary Report ------------------- t/configureReturn.t (Wstat: 11 Tests: 20 Failed: 0) Non-zero wait status: 11
Hi Slaven,

Would first like to confirm the Tcl/Tk patchlevel in use. Latest Tcl/Tk for CentOS 6 appears to be 8.5.7.

Could you run the test manually with perl -d to get a stack trace saying where the segmentation fault occurs?

Download (untitled) / with headers
text/plain 3.1k
On 2019-03-10 10:58:14, CAC wrote: Show quoted text
> Hi Slaven, > > Would first like to confirm the Tcl/Tk patchlevel in use. Latest > Tcl/Tk for > CentOS 6 appears to be 8.5.7.
$ rpm -q tcl tcl-8.5.7-6.el6.x86_64 $ rpm -q tk tk-8.5.7-5.el6.x86_64 Show quoted text
> > Could you run the test manually with perl -d to get a stack trace > saying where > the segmentation fault occurs?
Here's the C level stack trace: #0 0x00007f8d11b028f2 in Tk_FreeConfigOptions () from /usr/lib64/tk8.5/../ #1 0x00007f8d11b3355e in ?? () from /usr/lib64/tk8.5/../ #2 0x00007f8d11b36365 in ?? () from /usr/lib64/tk8.5/../ #3 0x00007f8d11b06ab9 in Tk_HandleEvent () from /usr/lib64/tk8.5/../ #4 0x00007f8d11b22671 in Tk_DestroyWindow () from /usr/lib64/tk8.5/../ #5 0x00007f8d11b222c8 in Tk_DestroyWindow () from /usr/lib64/tk8.5/../ #6 0x00007f8d126621ac in Tcl_DeleteCommandFromToken () from /usr/lib64/ #7 0x00007f8d126d6274 in TclTeardownNamespace () from /usr/lib64/ #8 0x00007f8d12663190 in ?? () from /usr/lib64/ #9 0x00007f8d1295715f in XS_Tcl__Finalize () from /opt/perl-5.28.0/lib/site_perl/5.28.0/x86_64-linux/auto/Tcl/ #10 0x00000000004be716 in Perl_pp_entersub () #11 0x00000000004bd983 in Perl_runops_standard () #12 0x000000000043ed98 in Perl_call_sv () #13 0x000000000043f362 in Perl_call_list () #14 0x0000000000440ed3 in perl_destruct () #15 0x000000000041fb34 in main () Last lines of the perl -d trace: 724: local($\, $,); # guard against -l and other things that screw with Test::skip(/opt/perl-5.28.0/lib/5.28.0/ 727: my $whyskip = _to_value(shift); Test::_to_value(/opt/perl-5.28.0/lib/5.28.0/ 225: my ($v) = @_; Test::_to_value(/opt/perl-5.28.0/lib/5.28.0/ 226: return ref $v eq 'CODE' ? $v->() : $v; Test::skip(/opt/perl-5.28.0/lib/5.28.0/ 728: if (!@_ or $whyskip) { Test::skip(/opt/perl-5.28.0/lib/5.28.0/ 729: $whyskip = '' if $whyskip =~ m/^\d+$/; Test::skip(/opt/perl-5.28.0/lib/5.28.0/ 730: $whyskip =~ s/^[Ss]kip(?:\s+|$)//; # backwards compatibility, old Test::skip(/opt/perl-5.28.0/lib/5.28.0/ 734: my $ok = "ok $ntest # skip"; Test::skip(/opt/perl-5.28.0/lib/5.28.0/ 735: $ok .= " $whyskip" if length $whyskip; Test::skip(/opt/perl-5.28.0/lib/5.28.0/ 736: $ok .= "\n"; Test::skip(/opt/perl-5.28.0/lib/5.28.0/ 737: print $TESTOUT $ok; ok 20 # skip NoteBook needs the Tixpackage which is not installed Test::skip(/opt/perl-5.28.0/lib/5.28.0/ 738: ++ $ntest; Test::skip(/opt/perl-5.28.0/lib/5.28.0/ 739: return 1; main::(t/configureReturn.t:34): next; Test::CODE(0x3806ca0)(/opt/perl-5.28.0/lib/5.28.0/ 759: $ONFAIL->(\@FAILDETAIL) if @FAILDETAIL && $ONFAIL; Tcl::CODE(0x2dae130)(/opt/perl-5.28.0/lib/site_perl/5.28.0/x86_64-linux/ 599: Tcl::_Finalize(); [1] 19207 segmentation fault (core dumped) perl5.28.0 -d -Mblib t/configureReturn.t
Could you please try adding


to the very bottom of configureReturn.t and see if that prevents this issue?

I'm wondering if tests—at least the ones that don't use MainLoop and after(1000, sub {$mw->destroy}) to remain open for a few seconds—are prone to having errors if there are still outstanding events, or if destroy() isn't called. They differ from ordinary programs which enter MainLoop and then call destroy() when the user closes the main window. However, instead of revising tests to enter idletasks() (with the added benefit of them running faster than when using after() ), I wonder if it should instead be safe for programs to end without processing outstanding events nor explicitly calling destroy().

I downloaded CentOS 6.10, and was able to reproduce this issue using Perl 5.10 and Tk 8.5 provided by CentOS.
The workaround I previously suggested ($mw->idletasks) did not seem to help. However, putting $mw->destroy at the very end of the test appears to eliminate the issue, so I will include that in a future version as a workaround.
I'm inclined to believe the issue here is an instance of the issue described in RT #128654, where things like segmentation faults can happen when using Perl exit before the MainWindow is destroyed. In normal Perl/Tk and Tcl::pTk usage, the user destroys the MainWindow, and then Perl exits. But many of Tcl::pTk's test scripts have not been manually destroying the MainWindow before the implicit Perl exit at the end of the test script. I don't know if the issue is in Tcl::pTk,, or in Tcl/Tk; but it would seem nothing bad should happen as a result of invoking Tcl/Tk's designated cleanup routine Tcl_Finalize() when Perl exits.
CentOS 6 will be EOL this year, and Tcl/Tk considers 8.5 to be effectively unsupported. I will probably only report this issue elsewhere if it affects a more recent platform or Tcl/Tk version.
Download (untitled) / with headers
text/plain 275b
On 2020-03-07 03:12:25, CAC wrote: [...] Show quoted text
> CentOS 6 will be EOL this year
But please consider that CentOS is just a cost-free clone of RHEL, and RHEL 6 is --- according to --- supported until 2024. Regards, Slaven

This service is sponsored and maintained by Best Practical Solutions and runs on infrastructure.

Please report any issues with to