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: arnold
Subject: Re: 5.2.{0,1} segfault when built against libsigsev on i686
Date: Wed, 30 Nov 2022 08:10:31 -0700
User-agent: Heirloom mailx 12.5 7/5/10

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
> >



reply via email to

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