emerge generates segmentation fault

albright

this morning - out of the blue as a gift from the gentoo gods -
when I ran emerge -uDav world, I received this after a *long wait*:

Calculating dependencies /Sandboxed process killed by signal: Segmentation fault
... done!

Then everything appeared to proceed normally.

Anyone know what's going on? TIA>
_________________
.... there is nothing - absolutely nothing - half so much worth
doing as simply messing about with Linux ...
(apologies to Kenneth Graeme)

albright · Posted: Mon Apr 26, 2010 4:44 pm Post subject:

some more information, from /var/log/messages:

platojones · Posted: Mon Apr 26, 2010 4:47 pm Post subject:

What have you updated lately? Bash, sandbox, toolchain, glibc? Anything?

NathanZachary · Moderator Joined: 30 Jan 2007 Posts: 2608

Output of emerge --info please.
_________________
“Truth, like infinity, is to be forever approached but never reached.” --Jean Ayres (1972)
---avatar cropped from =AimanStudio---

albright · Posted: Mon Apr 26, 2010 7:27 pm Post subject:

platojones · Posted: Mon Apr 26, 2010 7:36 pm Post subject:

albright · Posted: Mon Apr 26, 2010 8:14 pm Post subject:

here is emerge --info

platojones · Posted: Mon Apr 26, 2010 8:23 pm Post subject:

You and I have very similar configurations (even the same kernel). Nothing jumps out though.

This has me wondering:

albright · Posted: Mon Apr 26, 2010 9:56 pm Post subject:

krinn · Watchman Joined: 02 May 2003 Posts: 7470

distcc and march=native = roll a dice...

march=native = your current cpu optimization

distcc build something1 part in your computer -> march=native -> march=core2 cpu
distcc send to build something2 part in another computer (let's say a pentium2) -> march=native -> march=pentium2 and worst, chost x86...

except if your computers helpers are also core2 with chost also x86_64 you'll get into trouble...
and don't forget an amd64 helper running 64bits won't trouble you with x86_64, but still your core2 will dislike any code optimize with 3dnow and others stuff amd got.

nilekurt · n00b Joined: 30 Jan 2008 Posts: 20 Location: Sweden

I updated portage to 2.1.8.3 today and am experiencing exactly the same problem.

emerge --info:

krinn · Watchman Joined: 02 May 2003 Posts: 7470

so is your distcc 3.1, gcc version and glibc version also...

try FEATURES="-distcc" emerge blahblah

portage 2.1.8.3 too, but working here

platojones · Posted: Mon Apr 26, 2010 11:07 pm Post subject:

nilekurt · n00b Joined: 30 Jan 2008 Posts: 20 Location: Sweden

krinn · Watchman Joined: 02 May 2003 Posts: 7470

distcc disable because the daemon is disable only

if you look at mine, you'll see it's also disable, but my distcc is always working.
how: simple answer, distcc hosts using ssh, so distcc daemon is disable but working when another distcc sshing that computer.

so even portage says it's disable isn't proof distcc is...

leaving you with gcc, kernel, glibc in common

edit: lol, just saw newer portage says it's enable now

c00kiemon5ter · n00b Joined: 27 Apr 2010 Posts: 9 Location: (void *)null

same thing here as of yesterday using
amd64, march=native, no distcc, and zen kernel

trying to emerge and looking at htop:
/usr/lib64/portage/bin/ebuild.sh depend
is what takes most time to calculate

here is my emerge --info:

Hu · Administrator Joined: 06 Mar 2007 Posts: 22578

platojones · Posted: Tue Apr 27, 2010 2:28 am Post subject:

Well, I think it's safe to say we can rule out a hardware problem, based on the fact that it is happening to several people.

In all cases, using the latest Zen kernel, amd64, same glibc, same bash and stable portage. Same as me, except I am having no problem. Only thing I see in common is all explicitly use a variant of the -msse cflag...set to either 4.0 or 4.1.

I think this one will be tough to solve.

c00kiemon5ter · n00b Joined: 27 Apr 2010 Posts: 9 Location: (void *)null

Take a look at this, to see what we're talking about

eix and many if not all other seem normal

platojones · Posted: Tue Apr 27, 2010 3:03 am Post subject:

c00kiemon5ter · n00b Joined: 27 Apr 2010 Posts: 9 Location: (void *)null

platojones · Posted: Tue Apr 27, 2010 3:20 am Post subject:

Don't know what it is, but there is something you all have in common that krinn and I don't. I'll just post my emerge --info. Maybe somebody will spot the common thing that is different:

albright · Posted: Tue Apr 27, 2010 12:03 pm Post subject:

Well - one difference is the linux-headers. So I unmasked
linux-headers and emerged version 2.6.33 and rebuilt
glibc.

But no joy

_________________
.... there is nothing - absolutely nothing - half so much worth
doing as simply messing about with Linux ...
(apologies to Kenneth Graeme)

Nsane457 · n00b Joined: 25 Nov 2004 Posts: 45

Seems to be related to https://bugs.gentoo.org/show_bug.cgi?id=317297.

Unmerging zen-sources-9999 (still keeping and using the kernel source, though) worked for me.

albright · Posted: Tue Apr 27, 2010 2:17 pm Post subject:

great work, Nsane457

unmerging zen-sources-2.6.33_p1 fixes the problem
for me

now, just trying to emerge zen-sources again generates
the delay :roll:

and the errors (but works in the end nonetheless).

But why doesn't everyone with zen-sources have the problem???
_________________
.... there is nothing - absolutely nothing - half so much worth
doing as simply messing about with Linux ...
(apologies to Kenneth Graeme)