5.2.{0,1} segfault when built against libsigsev on i686

[Satadru Pramanik]

I'm updating gawk on the Chromebrew distribution, and we are noticing that
both 5.2.0 and 5.2.1 segfault when built against the current version of
libsigsev.

gdb reports this:
Program received signal SIGSEGV, Segmentation fault.
0x566fc1c0 in strcat ()

I managed to get our compiled binary up on an ubuntu/i386 system so I could
run it with valgrind, and I see this:

valgrind /tmp/gawk
==9783== Memcheck, a memory error detector
==9783== Copyright (C) 2002-2017, and GNU GPL'd, by Julian Seward et al.
==9783== Using Valgrind-3.13.0 and LibVEX; rerun with -h for copyright info
==9783== Command: /tmp/gawk
==9783==
==9783==
==9783== Process terminating with default action of signal 11 (SIGSEGV):
dumping core
==9783==  Bad permissions for mapped region at address 0x2ACE68
==9783==    at 0x20CF5E: ??? (in /tmp/gawk)
==9783== Invalid read of size 4
==9783==    at 0x2A8842: ??? (in /tmp/gawk)
==9783==  Address 0x4 is not stack'd, malloc'd or (recently) free'd
==9783==
==9783==
==9783== Process terminating with default action of signal 11 (SIGSEGV)
==9783==  Access not within mapped region at address 0x4
==9783==    at 0x2A8842: ??? (in /tmp/gawk)
==9783==  If you believe this happened as a result of a stack
==9783==  overflow in your program's main thread (unlikely but
==9783==  possible), you can try to increase the size of the
==9783==  main thread stack using the --main-stacksize= flag.
==9783==  The main thread stack size used in this run was 8388608.
==9783==
==9783== HEAP SUMMARY:
==9783==     in use at exit: 0 bytes in 0 blocks
==9783==   total heap usage: 0 allocs, 0 frees, 0 bytes allocated
==9783==
==9783== All heap blocks were freed -- no leaks are possible
==9783==
==9783== For counts of detected and suppressed errors, rerun with: -v
==9783== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 0 from 0)
Segmentation fault


Do you have any ideas on how to resolve this?

We have no problems with gawk when built against libsigsev on armv7l or
x86_64.

Thanks. This is for older devices with older kernels, but this certainly
doesn't work in our test docker environment, for which I'm happy to provide
setup information.

Regards,

Satadru