Bug 81829 - [7 Regression] /usr/bin/gcc-{ar,nm,ranlib} segfault without arguments
Summary: [7 Regression] /usr/bin/gcc-{ar,nm,ranlib} segfault without arguments
Status: RESOLVED FIXED
Alias: None
Product: gcc
Classification: Unclassified
Component: driver (show other bugs)
Version: 7.1.1
: P3 normal
Target Milestone: 7.3
Assignee: Martin Liška
URL:
Keywords:
: 80717 81991 (view as bug list)
Depends on:
Blocks:
 
Reported: 2017-08-11 19:53 UTC by Matthias Klose
Modified: 2021-12-24 08:48 UTC (History)
2 users (show)

See Also:
Host:
Target:
Build:
Known to work: 6.4.1, 8.0
Known to fail: 7.1.1
Last reconfirmed: 2017-08-12 00:00:00


Attachments
Patch candidate (2.62 KB, application/mbox)
2017-09-14 09:36 UTC, Martin Liška
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Matthias Klose 2017-08-11 19:53:27 UTC
[forwarded from http://bugs.debian.org/853537]

[7 Regression] /usr/bin/gcc-{ar,nm,ranlib} segfault without arguments when call with an absolute name:

$ gdb --args /usr/bin/gcc-ar

Program received signal SIGSEGV, Segmentation fault.
__strcpy_sse2_unaligned () at ../sysdeps/x86_64/multiarch/strcpy-sse2-unaligned.S:296
296     ../sysdeps/x86_64/multiarch/strcpy-sse2-unaligned.S: No such file or directory.
(gdb) bt
#0  __strcpy_sse2_unaligned () at ../sysdeps/x86_64/multiarch/strcpy-sse2-unaligned.S:296
#1  0x0000000000401a17 in find_a_file (pprefix=0x6061d0 <path>, name=0x4044e6 "ar", mode=1)
    at ../../src/gcc/file-find.c:81
#2  0x00000000004016ee in main (ac=1, av=0x7fffffffe598) at ../../src/gcc/gcc-ar.c:205
(gdb) up
#1  0x0000000000401a17 in find_a_file (pprefix=0x6061d0 <path>, name=0x4044e6 "ar", mode=1)
    at ../../src/gcc/file-find.c:81
81              strcpy (temp, pl->prefix);
(gdb) 

pl->prefix is NULL, set by remove_prefix

remove_prefix at the start has:

Breakpoint 1, remove_prefix (prefix=0x6070d0 "/usr/bin/", pprefix=0x6061d0 <path>)
    at ../../src/gcc/file-find.c:215
215       struct prefix_list *remove, **prev, **remove_prev = NULL;
(gdb) p *pprefix
$1 = {plist = 0x6070b0, max_len = 22, name = 0x0}
(gdb) p *pprefix->plist
$2 = {prefix = 0x607100 "/home/doko/bin/", next = 0x607120}
(gdb) p *pprefix->plist->next
$3 = {prefix = 0x607140 "/home/doko/.local/bin/", next = 0x607340}
(gdb) p *pprefix->plist->next->next
$4 = {prefix = 0x607360 "/usr/local/bin/", next = 0x607380}
(gdb) p *pprefix->plist->next->next->next
$5 = {prefix = 0x6073a0 "/usr/bin/", next = 0x6073c0}
(gdb) p *pprefix->plist->next->next->next->next
$6 = {prefix = 0x6073e0 "/bin/", next = 0x607400}
(gdb) p *pprefix->plist->next->next->next->next->next
$7 = {prefix = 0x607420 "/usr/local/games/", next = 0x607440}
(gdb) p *pprefix->plist->next->next->next->next->next->next
$8 = {prefix = 0x607460 "/usr/games/", next = 0x0}

and then at the end:

(gdb) p *remove_prev
$1 = (prefix_list *) 0x6073c0
(gdb) p **remove_prev
$2 = {prefix = 0x6073e0 "/bin/", next = 0x607400}

(gdb) p *pprefix->plist
$3 = {prefix = 0x607100 "/home/doko/bin/", next = 0x607120}
(gdb) p *pprefix->plist->next
$4 = {prefix = 0x607140 "/home/doko/.local/bin/", next = 0x607340}
(gdb) p *pprefix->plist->next->next
$5 = {prefix = 0x607360 "/usr/local/bin/", next = 0x607380}
(gdb) p *pprefix->plist->next->next->next
$6 = {prefix = 0x0, next = 0x6073c0}
(gdb) p *pprefix->plist->next->next->next->next
$7 = {prefix = 0x6073e0 "/bin/", next = 0x607400}
(gdb) p *pprefix->plist->next->next->next->next->next
$8 = {prefix = 0x607420 "/usr/local/games/", next = 0x607440}
(gdb) p *pprefix->plist->next->next->next->next->next->next
$9 = {prefix = 0x607460 "/usr/games/", next = 0x0}

looks like the next var of the previous entry is not correctly set.
Comment 1 Martin Liška 2017-08-12 10:06:46 UTC
Let me fix that.
Comment 2 Andrew Pinski 2017-08-26 07:50:26 UTC
*** Bug 81991 has been marked as a duplicate of this bug. ***
Comment 3 Xi Ruoyao 2017-08-26 10:12:47 UTC
marxin's patch:

http://gcc.gnu.org/ml/gcc-patches/2017-08/msg01116.html

But this patch doesn't work while /my_bin/bin contains a symlink.
Comment 4 Martin Liška 2017-08-28 07:23:11 UTC
(In reply to Xi Ruoyao from comment #3)
> marxin's patch:
> 
> http://gcc.gnu.org/ml/gcc-patches/2017-08/msg01116.html
> 
> But this patch doesn't work while /my_bin/bin contains a symlink.

Can you please describe your set up is more detail?
Comment 5 Xi Ruoyao 2017-08-29 01:26:03 UTC
(In reply to Martin Liška from comment #4)
> (In reply to Xi Ruoyao from comment #3)
> > marxin's patch:
> > 
> > http://gcc.gnu.org/ml/gcc-patches/2017-08/msg01116.html
> > 
> > But this patch doesn't work while /my_bin/bin contains a symlink.
> 
> Can you please describe your set up is more detail?

cd $BLDDIR
$SRCDIR/configure && make -j$CPUNUM
cd gcc
for i in ar nm ranlib; do ln -sv gcc-$i $i; done
export PATH=$PWD:$PATH
ar
(fork infinite processes)

Since my BLDDIR is /home/xry111/build/gcc, and /home/xry111/build is linked to
/mnt/mm1/xry111, remove_prefix failed to remove /home/xry111/build/gcc/gcc from
the prefixes.  If change to

export PATH=$(realpath $PWD):$PATH

It would be ok.
Comment 6 Martin Liška 2017-08-30 10:43:31 UTC
(In reply to Xi Ruoyao from comment #5)
> (In reply to Martin Liška from comment #4)
> > (In reply to Xi Ruoyao from comment #3)
> > > marxin's patch:
> > > 
> > > http://gcc.gnu.org/ml/gcc-patches/2017-08/msg01116.html
> > > 
> > > But this patch doesn't work while /my_bin/bin contains a symlink.
> > 
> > Can you please describe your set up is more detail?
> 
> cd $BLDDIR
> $SRCDIR/configure && make -j$CPUNUM
> cd gcc
> for i in ar nm ranlib; do ln -sv gcc-$i $i; done
> export PATH=$PWD:$PATH
> ar
> (fork infinite processes)
> 
> Since my BLDDIR is /home/xry111/build/gcc, and /home/xry111/build is linked
> to
> /mnt/mm1/xry111, remove_prefix failed to remove /home/xry111/build/gcc/gcc
> from
> the prefixes.  If change to
> 
> export PATH=$(realpath $PWD):$PATH
> 
> It would be ok.

Huh, so many beasts out there.
What can you see with following patch:

diff --git a/gcc/gcc-ar.c b/gcc/gcc-ar.c
index 1155ba83e35..452ca87d2ce 100644
--- a/gcc/gcc-ar.c
+++ b/gcc/gcc-ar.c
@@ -199,6 +199,8 @@ main (int ac, char **av)
 
       /* If the exe_name points to the wrapper, remove folder of the wrapper
 	 from prefix and try search again.  */
+      fprintf (stderr, "exe_name: %s, wrapper_file: %s\n", exe_name,
+	       wrapper_file);
       if (strcmp (exe_name, wrapper_file) == 0)
 	{
 	  char *exe_folder = wrapper_file;

It's probably related to lrealpath that does not follow links. Btw. is your link a mount?
I'm tending to remove the whole smartness of gcc-ar that removes the prefix.

Martin
Comment 7 Martin Liška 2017-09-14 09:36:15 UTC
Created attachment 42168 [details]
Patch candidate

So I eventually decided to remove the smartness in wrappers, let's make it simple. I've been testing that.
Comment 8 Martin Liška 2017-10-19 11:09:00 UTC
Author: marxin
Date: Thu Oct 19 11:08:28 2017
New Revision: 253886

URL: https://gcc.gnu.org/viewcvs?rev=253886&root=gcc&view=rev
Log:
Revert r238089 (PR driver/81829).

2017-10-19  Martin Liska  <mliska@suse.cz>

	PR driver/81829
	* file-find.c (remove_prefix): Remove.
	* file-find.h (remove_prefix): Likewise.
	* gcc-ar.c: Remove smartness of lookup.

Modified:
    trunk/gcc/ChangeLog
    trunk/gcc/file-find.c
    trunk/gcc/file-find.h
    trunk/gcc/gcc-ar.c
Comment 9 Martin Liška 2017-10-19 11:09:39 UTC
Fixed on trunk, queued for backports.
Comment 10 Martin Liška 2017-11-21 16:01:27 UTC
Author: marxin
Date: Tue Nov 21 16:00:55 2017
New Revision: 255009

URL: https://gcc.gnu.org/viewcvs?rev=255009&root=gcc&view=rev
Log:
Backport r253886

2017-11-21  Martin Liska  <mliska@suse.cz>

	Backport from mainline
	2017-10-19  Martin Liska  <mliska@suse.cz>

	PR driver/81829
	* file-find.c (remove_prefix): Remove.
	* file-find.h (remove_prefix): Likewise.
	* gcc-ar.c: Remove smartness of lookup.

Modified:
    branches/gcc-7-branch/gcc/ChangeLog
    branches/gcc-7-branch/gcc/file-find.c
    branches/gcc-7-branch/gcc/file-find.h
    branches/gcc-7-branch/gcc/gcc-ar.c
Comment 11 Martin Liška 2017-11-21 16:03:48 UTC
Fixed.
Comment 12 Andrew Pinski 2021-12-24 08:48:29 UTC
*** Bug 80717 has been marked as a duplicate of this bug. ***