Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 586288 - sys-devel/ct-ng-1.22.0: infinite recursion with sys-apps/install-xattr
Summary: sys-devel/ct-ng-1.22.0: infinite recursion with sys-apps/install-xattr
Status: CONFIRMED
Alias: None
Product: Gentoo Linux
Classification: Unclassified
Component: Current packages (show other bugs)
Hardware: All Linux
: Normal normal (vote)
Assignee: Anthony Basile
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2016-06-18 13:20 UTC by Pavel Goran
Modified: 2017-04-22 17:05 UTC (History)
2 users (show)

See Also:
Package list:
Runtime testing required: ---


Attachments
emerge --info (emerge.info,8.07 KB, application/x-info)
2016-06-18 13:20 UTC, Pavel Goran
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Pavel Goran 2016-06-18 13:20:45 UTC
Created attachment 437948 [details]
emerge --info

How to reproduce:

emerge ct-ng
mkdir test-toolchain
cd test-toolchain
ct-ng avr
ct-ng build
(in a different console)
watch pgrep install-xattr "|" wc -l

Here is what's going on. When crosstool-ng is built, the configure script discovers that "install" invocation should be done as "/usr/lib/portage/python2.7/ebuild-helpers/xattr/install -c" (supposedly because I have USE=xattr). This is written in "/usr/lib/crosstool-ng-1.22.0/paths.sh".

When "ct-ng build" prepares for building the toolchain, it creates the directory ".build/tools/bin" where it generates scripts for everything recorded in "/usr/lib/crosstool-ng-1.22.0/paths.sh", including the "install" script that invokes "/usr/lib/portage/python2.7/ebuild-helpers/xattr/install".

Then ".build/tools/bin" is put in PATH ahead of system paths, and "install something somewhere" is invoked. The local script executes "/usr/lib/portage/python2.7/xattr/install" which executes "install-xattr" which executes "install" which is the same local script, and everything repeats.
Comment 1 Pavel Goran 2016-06-18 13:34:18 UTC
To me, the sanest way to fix this would be modifying "install-xattr" so that it stopped examining PATH when looking for the actual "install". "install-xattr" already has an ability to find "install" when no PATH is set, so it's quite simple. It's a straightforward approach that would eliminate the (probably mostly) unneeded complication. It can break some esoteric use cases, but in a completely understandable way.

Other than that, the ct-ng ebuild can just patch "paths.sh" (along with the accompanying "paths.mk") by removing the offending line and allowing the build process to use whatever "install' it can find in PATH. It's a hackish way, though, and I don't know (yet) if it will work.
Comment 2 Alex Xu (Hello71) 2016-06-24 22:54:30 UTC
fyi this is not "fork bomb", fork bombs must be superlinear.
Comment 3 Anthony Basile gentoo-dev 2016-06-24 23:30:46 UTC
(In reply to Pavel Goran from comment #1)
> To me, the sanest way to fix this would be modifying "install-xattr" so that
> it stopped examining PATH when looking for the actual "install".
> "install-xattr" already has an ability to find "install" when no PATH is
> set, so it's quite simple. It's a straightforward approach that would
> eliminate the (probably mostly) unneeded complication. It can break some
> esoteric use cases, but in a completely understandable way.

if i changed this, we'd have to test it in all the environments in which install-xattr is used.  how can i be sure that removing the $PATH examining code will not break when "install" is installed in a non-standard location?

> 
> Other than that, the ct-ng ebuild can just patch "paths.sh" (along with the
> accompanying "paths.mk") by removing the offending line and allowing the
> build process to use whatever "install' it can find in PATH. It's a hackish
> way, though, and I don't know (yet) if it will work.

can you try that and send a patch my way.
Comment 4 hanetzer 2017-01-17 20:00:11 UTC
Still unfixed as of today.
Comment 5 Anthony Basile gentoo-dev 2017-04-22 17:05:32 UTC
(In reply to ntzrmtthihu777+gentoo from comment #4)
> Still unfixed as of today.

I just added 1.23.0 to the tree, but I'm sure it doesn't solve this.  I haven't had time to look but can someone check to see if the path to install is hard coded and points to install-xattr?  Maybe something as simple as a quick sed can fix thi.