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

[arnold]

So, I am stumped.  In any case, you have it working. I'd still
suggest asking the libsigsegv developers; it's not a gawk issue.

Thanks,

Arnold

Satadru Pramanik <satadru@gmail.com> wrote:

> This is from the working gawk:
>
> gawk -V
> GNU Awk 5.2.1, API 3.2, (GNU MPFR 4.1.0-p11, GNU MP 6.2.1)
> Copyright (C) 1989, 1991-2022 Free Software Foundation.
>
> This program is free software; you can redistribute it and/or modify
> it under the terms of the GNU General Public License as published by
> the Free Software Foundation; either version 3 of the License, or
> (at your option) any later version.
>
> This program is distributed in the hope that it will be useful,
> but WITHOUT ANY WARRANTY; without even the implied warranty of
> MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
> GNU General Public License for more details.
>
> You should have received a copy of the GNU General Public License
> along with this program. If not, see http://www.gnu.org/licenses/.
>
> lddtree `which gawk`
> /usr/local/bin/gawk (interpreter => /lib/ld-linux.so.2)
>     /usr/local/lib/libsigsegv.so.2 => /usr/local/lib/libsigsegv.so.2
>     /usr/local/lib/libreadline.so.8 => /usr/local/lib/libreadline.so.8
>         /usr/local/lib/libtinfow.so.6 => /usr/local/lib/libtinfow.so.6
>     /usr/local/lib/libmpfr.so.6 => /usr/local/lib/libmpfr.so.6
>         libgmp.so.10 => /usr/local/lib/libgmp.so.10
>     /usr/local/lib/libgmp.so.10 => /usr/local/lib/libgmp.so.10
>     libdl.so.2 => /usr/local/lib/libdl.so.2
>     /usr/local/lib/libm.so.6 => /usr/local/lib/libm.so.6
>     libc.so.6 => /usr/local/lib/libc.so.6
>
> This is from the non-working gawk:
> /output/gawk -V
> Segmentation fault (core dumped)
>
> lddtree /output/gawk
> /output/gawk (interpreter => /lib/ld-linux.so.2)
>     /usr/local/lib/libsigsegv.so.2 => /usr/local/lib/libsigsegv.so.2
>     /usr/local/lib/libreadline.so.8 => /usr/local/lib/libreadline.so.8
>         /usr/local/lib/libtinfow.so.6 => /usr/local/lib/libtinfow.so.6
>     /usr/local/lib/libmpfr.so.6 => /usr/local/lib/libmpfr.so.6
>         libgmp.so.10 => /usr/local/lib/libgmp.so.10
>     /usr/local/lib/libgmp.so.10 => /usr/local/lib/libgmp.so.10
>     libdl.so.2 => /usr/local/lib/libdl.so.2
>     /usr/local/lib/libm.so.6 => /usr/local/lib/libm.so.6
>     /usr/local/lib/libgcc_s.so.1 => /usr/local/lib/libgcc_s.so.1
>     libc.so.6 => /usr/local/lib/libc.so.6
>
> On Wed, Nov 30, 2022, 10:10 AM <arnold@skeeve.com> wrote:
>
> > I suggest sending in a libsigsegv bug report. Maybe ldd on the
> > good and bad binaries can shed some light....
> >
> > Arnold
> >
> > Satadru Pramanik <satadru@gmail.com> wrote:
> >
> > > Gawk fails even running it without anything passed to it.
> > >
> > > Weirdly, passing "--without-libsigsegv-prefix" to configure seems to fix
> > > the built binary, even though it also ends up creating a binary linked to
> > > libsigsev.
> > >
> > >
> > > I can't explain it...
> > >
> > > On Wed, Nov 30, 2022, 3:56 AM <arnold@skeeve.com> wrote:
> > >
> > > > Hi.
> > > >
> > > > Does gawk fail across the board, or just on a specific program or test?
> > > >
> > > > I suggest for now just configuring without libsigsegv.  I have been
> > > > considering dropping the use of libsigsegv anyway...
> > > >
> > > > Otherwise I don't have any specific advice.
> > > >
> > > > Arnold
> > > >
> > > > Satadru Pramanik <satadru@gmail.com> wrote:
> > > >
> > > > > 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
> > > >
> >