bug-gawk
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Satadru Pramanik
Subject: Re: 5.2.{0,1} segfault when built against libsigsev on i686
Date: Wed, 30 Nov 2022 08:49:01 -0500

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
>


reply via email to

[Prev in Thread] Current Thread [Next in Thread]