bug-gnulib@gnu.org mirror (unofficial)
 help / color / mirror / Atom feed
From: Paul Eggert <eggert@cs.ucla.edu>
To: Bruce Dubbs <bruce.dubbs@gmail.com>, Jim Meyering <jim@meyering.net>
Cc: Gnulib bugs <bug-gnulib@gnu.org>,
	GNU grep developers <grep-devel@gnu.org>
Subject: Re: new snapshot available: grep-3.4-almost.26-5419
Date: Fri, 18 Sep 2020 15:16:40 -0700	[thread overview]
Message-ID: <4ebb160d-e168-7051-a6a1-3a218b7e2ba9@cs.ucla.edu> (raw)
In-Reply-To: <994fd316-0420-4b94-a1de-fea7d891c4ac@gmail.com>

[-- Attachment #1: Type: text/plain, Size: 2318 bytes --]

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

and all 93 tests succeeded.  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)
$ gltests/test-c-stack
test-c-stack: stack overflow
$ gltests/test-c-stack 1
test-c-stack: program error
Aborted (core dumped)

[-- Attachment #2: c-stack-test.tgz --]
[-- Type: application/x-compressed-tar, Size: 836712 bytes --]

       reply	other threads:[~2020-09-19  0:54 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <m2a6xnu1sv.fsf@meyering.net>
     [not found] ` <075a970b-f6aa-d2bb-e007-609a711085b2@gmail.com>
     [not found]   ` <CA+8g5KGBjFfHzafN2WFH6az5bQR8f68B1J-ETVWEBXvuDUL5rA@mail.gmail.com>
     [not found]     ` <17a0fe42-3ac6-9209-6f60-cddb5467f263@gmail.com>
     [not found]       ` <994fd316-0420-4b94-a1de-fea7d891c4ac@gmail.com>
2020-09-18 22:16         ` Paul Eggert [this message]
2020-09-18 22:42           ` new snapshot available: grep-3.4-almost.26-5419 Bruce Dubbs
2020-09-18 23:24             ` libsigsegv on LinuxFromScratch Bruno Haible
2020-09-18 23:47               ` Bruce Dubbs
2020-09-19  8:06                 ` Bruce Dubbs
2020-09-19 23:47                   ` Bruno Haible
2020-09-20  1:16                     ` Bruce Dubbs
2020-09-20 23:15                     ` Paul Eggert
2020-09-23  0:58                       ` stack bounds Bruno Haible
2020-09-23  1:28                         ` Paul Eggert
2020-10-10 12:08                           ` Bruno Haible
2020-10-10 20:10                             ` Paul Eggert
2020-10-10 21:49                               ` Bruno Haible
2020-10-11 18:49                                 ` Paul Eggert
2020-10-11 22:08                                   ` Bruno Haible
2020-10-11 22:56                                     ` Paul Eggert

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://lists.gnu.org/mailman/listinfo/bug-gnulib

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4ebb160d-e168-7051-a6a1-3a218b7e2ba9@cs.ucla.edu \
    --to=eggert@cs.ucla.edu \
    --cc=bruce.dubbs@gmail.com \
    --cc=bug-gnulib@gnu.org \
    --cc=grep-devel@gnu.org \
    --cc=jim@meyering.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).