Tk build/test fails (Perl 5.38, SP 5.38.0.1-64bit-portable)

[greggmorris]

This problem appears similar to Tk build fails (Perl 5.36 sp536 20230420). I first tried to install Tk using CPAN. I had to add the patch described here to get the build to succeed, but the first test fails:

Test Summary Report
-------------------
t/basic.t (Wstat: 1280 (exited 5) Tests: 2 Failed: 0)
  Non-zero exit status: 5
  Parse errors: Bad plan.  You planned 5 tests but ran 2.
t/crash.t (Wstat: 1280 (exited 5) Tests: 0 Failed: 0)
  Non-zero exit status: 5
  Parse errors: Bad plan.  You planned 1 tests but ran 0.
Files=2, Tests=2,  3 wallclock secs ( 0.08 usr +  0.03 sys =  0.11 CPU)
Result: FAIL
Failed 2/2 test programs. 0/2 subtests failed.
gmake[1]: *** [makefile:867: test_dynamic] Error 5
gmake[1]: Leaving directory 'C:/SP538/mod_bld/Tk-804.036/PNG'
gmake: *** [makefile:1453: subdirs-test_dynamic] Error 2

I then tried to build Tk manually in an MSYS2 environment, with the same patch installed. I can supply log files for the Tk build, if that would be helpful. The test behavior was identical, it failed the same way as above on the first test. In an effort to get more information, I ran the first test manually, outside the test framework:

$ perl t/basic.t
1..5
ok 1 - use Tk::PNG;
ok 2 - Loaded PNG image from C:/SP538/mod_bld/Tk-804.036/PNG/t/../pngtest.png
Segmentation fault

I'm not familiar with Perl module development or test frameworks. Is "exit status 5" a Windows ERROR_ACCESS_DENIED error? It looks like the segfault occurs on the following call (line 29 in Tk-804.036/PNG/t/basic.t):

    $mw->Label(-image => $image)->pack;

I looked in the Tk doc but I didn't see anything about the Label function or image option that gave me a clue about what I am being denied access to, if that is indeed a relevant error code. I thought I might learn something about the segfault by running perl and the test under gdb, but as you can see, the test ran fine.

$ gdb /c/SP538/perl/bin/perl.exe
GNU gdb (GDB) 13.2
Copyright (C) 2023 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
Type "show copying" and "show warranty" for details.
This GDB was configured as "x86_64-w64-mingw32".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
<https://www.gnu.org/software/gdb/bugs/>.
Find the GDB manual and other documentation resources online at:
    <http://www.gnu.org/software/gdb/documentation/>.

For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from C:/SP538/perl/bin/perl.exe...
(No debugging symbols found in C:/SP538/perl/bin/perl.exe)
(gdb) r t/basic.t
Starting program: C:\SP538\perl\bin\perl.exe t/basic.t
[New Thread 5868.0x248c]
[New Thread 5868.0x2fe0]
[New Thread 5868.0x17a4]
[New Thread 5868.0x27b8]
1..5
ok 1 - use Tk::PNG;
ok 2 - Loaded PNG image from C:/SP538/mod_bld/Tk-804.036/PNG/t/../pngtest.png
ok 3 - Loaded PNG image from base64 encoded data
ok 4 - Roundtrip image data
ok 5 # skip Loading PNG image from binary data NYI *TODO*
[New Thread 5868.0x2bc0]
[New Thread 5868.0x1ecc]
[Thread 5868.0x27b8 exited with code 0]
[Thread 5868.0x17a4 exited with code 0]
[Thread 5868.0x1ecc exited with code 0]
[Thread 5868.0x2fe0 exited with code 0]
[Thread 5868.0x2bc0 exited with code 0]
[Thread 5868.0x248c exited with code 0]
[Inferior 1 (process 5868) exited normally]
(gdb)

I tried the second test and it worked fine as well:

(gdb) r t/crash.t
Starting program: C:\SP538\perl\bin\perl.exe t/crash.t
[New Thread 3740.0xce8]
[New Thread 3740.0xd48]
[New Thread 3740.0x3240]
[New Thread 3740.0x1058]
1..1
ok 1 - No crash while resizing a window with PNG image
[Thread 3740.0x1058 exited with code 0]
[Thread 3740.0xce8 exited with code 0]
[Thread 3740.0xd48 exited with code 0]
[Thread 3740.0x3240 exited with code 0]
[Inferior 1 (process 3740) exited normally]

I am at a loss. I recently built Perl 5.38 on a Red Hat 8 system and had no problems installing the Tk module. Has anyone found a workaround for this? Unfortunately, we need the vulnerability updates in Perl 5.38 and the Tk module is a requirement for us, so we won't be able to move forward with Perl 5.38 until we solve this problem.
Any suggestions would be greatly appreciated.

[shawnlaffan]

Thanks for the report.

This looks like an issue with Tk rather than Strawberry Perl itself so it should probably be reported there. Having it also here is likely to get more eyes on the problem, though, so we should keep this open.

WRT it passing under gdb, try setting set disable-randomization off before calling run. That seems to increase the chances of replication.

Some possible things to check are:

• There were issues with the t1lib under Imager where t1lib was casting 64 bit pointers to 32 bit signed and back. There might be something similar going on with Tk? See T1 tests fail under Strawberry perl 5.36 and 5.38, gcc13.1 tonycoz/imager#510 (comment)

• There were similar size issues with MCE. See Task::Kensho install failures. #103 (comment)

[sisyphus]

There were issues with the t1lib under Imager where t1lib was casting 64 bit pointers to 32 bit signed and back. There might be something similar going on with Tk?

Most of the conversion warnings in Tk are for conversions between pointer and int. Such conversions should be just as problematic on Linux as on Windows.
There are also some warnings about casts from pointer to long - and these would be an issue only on 64-bit Windows, as pointer and long are always the same size on other systems (AFAIK).
Even then it's only a problem if the pointer overflows the long.

However, if that is our problem with Tk-804.036 on 64-bit SP-5.38.0, then I would expect the very same problem to be present with Tk-804.036 on 64-bit SP-5.32.1.
Yet, Tk-804.036 builds and tests fine on SP-5.32.1 (both x64 and x86).

It would be nice to have a 32-bit SP-5.38.0 on which to test Tk-804.036. (On such a platform pointer/int/long conversions are not an issue because they're all the same size.)

On my own 32-bit builds of perl-5.38.0, the build dies trying to utilize the png library that ships with Tk-804.036, and (so far) I've been averse to working around that issue by building and utilizing a functional libpng library.

Cheers,
Rob

[greggmorris]

There is a fix for this problem described in the thread here.

[shawnlaffan]

Thanks @greggmorris - that's good news.

The gdb steps in that issue are also very useful.

I'll close this issue now since the issue is with Tk, there is a fix available, and we don't distribute Tk with Strawberry (but maybe one day).