grep-devel
[Top][All Lists]
Advanced

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

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


From: Bruce Dubbs
Subject: Re: new snapshot available: grep-3.4-almost.26-5419
Date: Fri, 18 Sep 2020 17:42:28 -0500
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.5.0

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



reply via email to

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