Bug 36370 – sys-devel/gcc-3.3.2-r4 - __guard binary scan hangs

• Product: Gentoo Linux
• Status: RESOLVED FIXED

[Description Toby Irvine 2003-12-23 07:43:09 UTC]

sys-devel/gcc-3.3.2-r4 appeared in an `emerge -uv world` recently (I am using ACCEPT_KEYWORDS="~x86").  The ebuild process reaches:

* This sys-libs/glibc has __guard object and __stack_smash_handler functions
* scanning the system for binaries with __guard - this may take 5-10 minutes
* Please do not press crtl-C or crtl-Z during this period - it will continue

An output from `top` at this time:

 PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
6849 root 25 0 1672 672 1476 R 71.5 0.1 246:53.00 readelf
5609 root 15 0 1532 620 1364 S 25.9 0.1 91:16.15 grep

So something is happening, but I have previously left it for an entire day and the ebuild has not proceeded any further.  I have run an `emerge sync` daily over the last few days and re-tried emerging gcc but the problem persists.

There is nothing unusual about my system and I have taken the step of unmounting any large filesystems, leaving just the few gigs of gentoo install I have, to prevent the scan from having to trawl large home and media directories.

Reproducible: Always
Steps to Reproduce:
1. Run `emerge -uv world`

Actual Results:  
Gcc 3.3.2-r4 ebuild commences, but doesn't get beyond the __guard binary scan.

Expected Results:  
The scan should finish and the ebuild should proceed.

Linux zak 2.6.0-test11 #3 Wed Dec 17 20:15:35 GMT 2003 i686 Intel(R) Pentium(R)
4 CPU 1.80GHz GenuineIntel GNU/Linux

An up-to-date gentoo ~x86 system running KDE, `emerge -uv world` run in Konsole.

[Comment 1 solar (RETIRED) 2003-12-23 12:16:57 UTC]

ouch that sounds pretty nasty.

Can you give us some debug info such as your SHELL, 
lsof of whats happening when this is triggered, some strace info on the readelf,grep 

Be sure any strace info does not contain any sensative information.

I'm thinking it's stuck in a read() of stdin.

On another note I'm working on an ELF util that will scan your file system for ELF  files for binarys that contain symbols by name. That slow find made me sick but it's a needed step for people that use -fstack-protector.

[Comment 2 Toby Irvine 2003-12-23 14:59:20 UTC]

Created attachment 22597 [details]
gzipped text file containing output of several diagnostic tools

[Comment 3 Toby Irvine 2003-12-23 15:03:15 UTC]

Forgot to include: SHELL = /bin/bash

Apologies for lengthy output from strace, it was curtailed as quickly as I could ctrl+c and I didn't want to remove information.

[Comment 4 solar (RETIRED) 2003-12-24 11:24:57 UTC]

Please reattach in non binary format. Sorry I dont trust binary formats.

[Comment 5 Toby Irvine 2003-12-28 06:28:55 UTC]

Created attachment 22740 [details]
Collected diagnostic tool outputs.

Re-attached as plain text.

[Comment 6 solar (RETIRED) 2004-01-08 02:18:31 UTC]

Thanks for attaching.
Does the current revision in portage work for you now?
It still uses readelf ;/

[Comment 7 Toby Irvine 2004-01-08 04:12:07 UTC]

The latest version hung on Step 19 - scanning /usr/sbin.

On investigating I found a strange binary, a.out, a quick `strings` showed the help text for parted - the partitioning utility.  On removal of this binary step 19 completed successfully and the ebuild completed without error.

I haven't compiled anything outside of portage so I have no idea how it got there.  Nor why it would cause the binary scan to hang.  I have kept the a.out binary file if it is of any interest.

[Comment 8 solar (RETIRED) 2004-01-27 17:43:52 UTC]

scripts have been rewritten. should not cause a problem for anybody anymore.
closing bug