Re: new snapshot available: grep-3.4-almost.26-5419

[Bruce Dubbs]

On 9/18/20 5:16 PM, Paul Eggert wrote:
> In <https://lists.gnu.org/r/grep-devel/2020-09/msg00052.html> on 9/18/20 
> 2:00 PM, Bruce Dubbs wrote:
> > ... if I run ./configure --prefix=/usr --bindir=/bin grep wants to 
> > link with /usr/lib/libsigsegv.so /usr/lib/libc.a instead of just 
> > -lsigsegv
> > In this later case, grep segfaults early.
> >
> > If I remove /usr/lib/libc.a, everything is fine.  I do not know why 
> > configure wants to use a static libc if the destination libraries are 
> > specified.
> >
> > Is this possibly a gnulib issue?
>
> Yes, most likely it's induced by grep's use of Gnulib's libsigsegv 
> module. I'll cc. this email to the Gnulib mailing list.
>
> To help narrow this down, let's try to reproduce the problem in Gnulib, 
> without having grep be involved. I created the attached tarball from 
> Gnulib master with the commands:
>
> ./gnulib-tool --create-testdir --dir c-stack-test c-stack
> tar czf c-stack-test.tgz c-stack-test
>
> Please run the following commands on your end and see whether they cause 
> a similar failure:
>
> tar xf c-stack-test.tgz
> cd c-stack-test
> ./configure --prefix=/usr --bindir=/bin
> make check
>
> I ran that on my Ubuntu 18.04.5 x86-64 platform and got output that 
> contained this:
>
> ...
> checking for working C stack overflow detection... yes
> checking for correct stack_t interpretation... yes
> checking for precise C stack overflow detection... no
> checking for ld used by gcc... /usr/bin/ld
> checking if the linker (/usr/bin/ld) is GNU ld... yes
> checking for shared library run path origin... done
> checking 32-bit host C ABI... no
> checking for ELF binary format... yes
> checking for the common suffixes of directories in the library search 
> path... lib,lib,lib
> checking for libsigsegv... yes
> checking how to link with libsigsegv... -lsigsegv

I get:

checking for libsigsegv... yes
checking how to link with libsigsegv... /usr/lib/libsigsegv.so 
/usr/lib/libc.a


Do you have /usr/lib/libc.a ?

I'll note that we do 'strip --strip-debug' on libc.a


> and all 93 tests succeeded.  


   dummy 0: ./test-suite.log
===============================

# TOTAL: 93
# PASS:  91
# SKIP:  0
# XFAIL: 0
# FAIL:  2
# XPASS: 0
# ERROR: 0

.. contents:: :depth: 2

FAIL: test-c-stack.sh
=====================

./test-c-stack.sh: line 7: 18000 Segmentation fault      ${CHECKER} 
./test-c-stack${EXEEXT} 2> t-c-stack.tmp
FAIL test-c-stack.sh (exit status: 1)

FAIL: test-c-stack2.sh
======================

FAIL test-c-stack2.sh (exit status: 1)

> Here are a few more things I tried and 
> where I got the expected results; please compare them to your platform too.
>
> $ ldd gltests/test-c-stack
>      linux-vdso.so.1 (0x00007ffcf55e9000)
>      libsigsegv.so.2 => /usr/lib/x86_64-linux-gnu/libsigsegv.so.2 
> (0x00007f28136f9000)
>      libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f2813308000)
>      /lib64/ld-linux-x86-64.so.2 (0x00007f2813b04000)

$ ldd gltests/test-c-stack
        linux-vdso.so.1 (0x00007ffd62100000)
        libsigsegv.so.2 => /usr/lib/libsigsegv.so.2 (0x00007f3d0f843000)
        libgcc_s.so.1 => /usr/lib/libgcc_s.so.1 (0x00007f3d0f829000)
        libc.so.6 => /lib/libc.so.6 (0x00007f3d0f663000)
        /lib64/ld-linux-x86-64.so.2 (0x00007f3d0f86f000

> $ gltests/test-c-stack
> test-c-stack: stack overflow

$ gltests/test-c-stack
Segmentation fault

> $ gltests/test-c-stack 1
> test-c-stack: program error
> Aborted (core dumped)

Segmentation fault

  -- Bruce