Skip Menu |
 

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

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

People
Owner: Nobody in particular
Requestors: SREZIC [...] cpan.org
Cc:
AdminCc:

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/../libtk8.5.so #1 0x00007f8d11b3355e in ?? () from /usr/lib64/tk8.5/../libtk8.5.so #2 0x00007f8d11b36365 in ?? () from /usr/lib64/tk8.5/../libtk8.5.so #3 0x00007f8d11b06ab9 in Tk_HandleEvent () from /usr/lib64/tk8.5/../libtk8.5.so #4 0x00007f8d11b22671 in Tk_DestroyWindow () from /usr/lib64/tk8.5/../libtk8.5.so #5 0x00007f8d11b222c8 in Tk_DestroyWindow () from /usr/lib64/tk8.5/../libtk8.5.so #6 0x00007f8d126621ac in Tcl_DeleteCommandFromToken () from /usr/lib64/libtcl8.5.so #7 0x00007f8d126d6274 in TclTeardownNamespace () from /usr/lib64/libtcl8.5.so #8 0x00007f8d12663190 in ?? () from /usr/lib64/libtcl8.5.so #9 0x00007f8d1295715f in XS_Tcl__Finalize () from /opt/perl-5.28.0/lib/site_perl/5.28.0/x86_64-linux/auto/Tcl/Tcl.so #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/Test.pm:727): 727: my $whyskip = _to_value(shift); Test::_to_value(/opt/perl-5.28.0/lib/5.28.0/Test.pm:225): 225: my ($v) = @_; Test::_to_value(/opt/perl-5.28.0/lib/5.28.0/Test.pm:226): 226: return ref $v eq 'CODE' ? $v->() : $v; Test::skip(/opt/perl-5.28.0/lib/5.28.0/Test.pm:728): 728: if (!@_ or $whyskip) { Test::skip(/opt/perl-5.28.0/lib/5.28.0/Test.pm:729): 729: $whyskip = '' if $whyskip =~ m/^\d+$/; Test::skip(/opt/perl-5.28.0/lib/5.28.0/Test.pm:730): 730: $whyskip =~ s/^[Ss]kip(?:\s+|$)//; # backwards compatibility, old Test::skip(/opt/perl-5.28.0/lib/5.28.0/Test.pm:734): 734: my $ok = "ok $ntest # skip"; Test::skip(/opt/perl-5.28.0/lib/5.28.0/Test.pm:735): 735: $ok .= " $whyskip" if length $whyskip; Test::skip(/opt/perl-5.28.0/lib/5.28.0/Test.pm:736): 736: $ok .= "\n"; Test::skip(/opt/perl-5.28.0/lib/5.28.0/Test.pm:737): 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/Test.pm:738): 738: ++ $ntest; Test::skip(/opt/perl-5.28.0/lib/5.28.0/Test.pm:739): 739: return 1; main::(t/configureReturn.t:34): next; Test::CODE(0x3806ca0)(/opt/perl-5.28.0/lib/5.28.0/Test.pm:759): 759: $ONFAIL->(\@FAILDETAIL) if @FAILDETAIL && $ONFAIL; Tcl::CODE(0x2dae130)(/opt/perl-5.28.0/lib/site_perl/5.28.0/x86_64-linux/Tcl.pm:599): 599: Tcl::_Finalize(); [1] 19207 segmentation fault (core dumped) perl5.28.0 -d -Mblib t/configureReturn.t
Could you please try adding

$mw->idletasks;

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().



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

Please report any issues with rt.cpan.org to rt-cpan-admin@bestpractical.com.