[gentoo-amd64] gcc 4.1.1 access violation

[gentoo-amd64] gcc 4.1.1 access violation

[Harry Holt]

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

Arrgh!  It did it again!  I have no idea how to fix this.  GCC will not
compile.  Well... I think it compiles, but then dies at the end.  I tried
running through the install/postinst/qmerge steps in ebuild, but that
doesn't seem to work (everything is still broken).  revdep-rebuild wants to
emerge GCC first - there are several things broken, including libfbdirect.

gzipping man page: std::wstring.3
gzipping man page: _var_tmp_portage_gcc-4.1.1_work_gcc-4.1.1_.3
>>> Completed installing gcc-4.1.1 into /var/tmp/portage/gcc-4.1.1/image/

--------------------------- ACCESS VIOLATION SUMMARY
---------------------------
LOG FILE = "/var/log/sandbox/sandbox-sys-devel_-_gcc-4.1.1-30225.log"

unlink:    /usr/lib64/crt1.o
open_wr:   /usr/lib64/crt1.o
unlink:    /usr/lib64/crt1.o
--------------------------------------------------------------------------------

maybe my use flags?

# emerge -pv gcc

These are the packages that would be merged, in order:

Calculating dependencies... done!
[ebuild   R   ] sys-devel/gcc-4.1.1  USE="doc fortran gcj gtk nls objc
(-altivec) -bootstrap -build (-hardened) -ip28 -ip32r10k -mudflap
(-multilib) -multislot (-n32) (-n64) -nocxx -objc++ -objc-gc -test -vanilla"
0 kB

How do I troubleshoot this?

-- 
Harry Holt, PMP

[-- Attachment #2: Type: text/html, Size: 1485 bytes --]

[gentoo-amd64] Re: gcc 4.1.1 access violation

[Duncan]

"Harry Holt" <harryholt@gmail.com> posted
7c8072a00610271620o15838e70of02ad445af47849d@mail.gmail.com, excerpted
below, on  Fri, 27 Oct 2006 19:20:39 -0400:

> Arrgh!  It did it again!  I have no idea how to fix this.  GCC will not
> compile.  Well... I think it compiles, but then dies at the end.  I tried
> running through the install/postinst/qmerge steps in ebuild, but that
> doesn't seem to work (everything is still broken).  revdep-rebuild wants
> to emerge GCC first - there are several things broken, including
> libfbdirect.
> 
> gzipping man page: std::wstring.3
> gzipping man page: _var_tmp_portage_gcc-4.1.1_work_gcc-4.1.1_.3
>>>> Completed installing gcc-4.1.1 into /var/tmp/portage/gcc-4.1.1/image/

OK, yes, it finishes the "fakeinstall" step here, which is after the
compile step, so it's done with that.

> 
> --------------------------- ACCESS VIOLATION SUMMARY
> ---------------------------
> LOG FILE = "/var/log/sandbox/sandbox-sys-devel_-_gcc-4.1.1-30225.log"
> 
> unlink:    /usr/lib64/crt1.o
> open_wr:   /usr/lib64/crt1.o
> unlink:    /usr/lib64/crt1.o
> --------------------------------------------------------------------------------

Sandbox violation.  Sandbox is a protection mechanism that is supposed to
keep the ebuild from overwriting anything on the main system during the
compile and install steps, which should be done to temporary locations,
prior to the qmerge to the main system.

$equery b crt1.o
[ Searching for file(s) crt1.o in *... ]
sys-libs/glibc-2.5 (/usr/lib32/crt1.o)
sys-libs/glibc-2.5 (/usr/lib64/crt1.o)

OK, so that file belongs to glibc, not gcc.  Why is gcc trying to unlink
it, then write to it, then unlink it again?  That's strange.

You /could/ try turning sandbox off (in FEATURES).  That's a bit dangerous
by itself, but if you turn userpriv on at the same time, it should be
fairly safe.  YOu can try it but I'm guessing it'll still fail, as the
portage user won't (for good reason!) have privs to delete the file either.

If userpriv doesn't work, you can try without either sandbox or userpriv,
just to be sure.  HOWEVER, I'd be very sure I had a backup of that file
and preferably my system first, just in case.  Additionally, messing with
glibc stuff is asking to see your system crash, so I'd not recommend
running anything else critical during this test.  Actually, I'd not
recommend running it at all, without first checking bugzilla and filing a
bug on it if necessary.  If a toolchain/gcc dev tells you to try it without
sandbox and userpriv, /then/ I'd feel a bit safer with it.  I might
personally try it here anyway, but I wouldn't feel right recommending that
others try it.

In any case, even if FEATURES="-sandbox userpriv" works, it's still worth
checking to see if a bug has been filed and filing one yourself if not. 
If it's OK to do, the devs might simply disable sandbox checking for that
file.  However, that doesn't look to me like something it should be
touching, in which case they need to figure out why it's happening and fix
the problem, so others don't run into it.

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman

-- 
gentoo-amd64@gentoo.org mailing list

Re: [gentoo-amd64] Re: gcc 4.1.1 access violation

[Hemmann, Volker Armin]

On Saturday 28 October 2006 07:02, Duncan wrote:

> You /could/ try turning sandbox off (in FEATURES).  That's a bit dangerous
> by itself, but if you turn userpriv on at the same time, it should be
> fairly safe.  

NO!

Just no!

Never ever turn of sandbox. Without sandbox, files can end everywhere in your 
installation, destroying stuff, make apps segfault randomly - and the worst, 
portage does not know about them.

Never ever turn of sandbox. And never tell others to do so.
btw
*  sys-devel/gcc
      Latest version available: 4.1.1-r1
      Latest version installed: 4.1.1-r1

and I have sandbox enabled. So it is not a sandbox problem. Something else is 
broken on his system.
-- 
gentoo-amd64@gentoo.org mailing list

[gentoo-amd64] Re: gcc 4.1.1 access violation

[Duncan]

"Hemmann, Volker Armin" <volker.armin.hemmann@tu-clausthal.de> posted
200610281108.21396.volker.armin.hemmann@tu-clausthal.de, excerpted below,
on  Sat, 28 Oct 2006 11:08:21 +0200:

> On Saturday 28 October 2006 07:02, Duncan wrote:
> 
>> You /could/ try turning sandbox off (in FEATURES).  That's a bit
>> dangerous by itself, but if you turn userpriv on at the same time, it
>> should be fairly safe.
> 
> NO!
> 
> Just no!
> 
> Never ever turn of sandbox. Without sandbox, files can end everywhere in
> your installation, destroying stuff, make apps segfault randomly - and the
> worst, portage does not know about them.
> 
> Never ever turn of sandbox. And never tell others to do so. btw

Wow, and I thought /I/ was a bit strict on that!  FWIW, you are right, to
a point.  Sandbox is there as a protection measure and turning it off can
be dangerous, as I said.  However, it's /not/ the end of the world! 
Ebuilds can and routinely do turn it off or tell it to ignore specific
parts of the filesystem when it gets in the way of what the build needs to
do.  Sandbox is just there to keep the unexpected from happening.

Anyway, userpriv works quite well too, as it should, because it uses the
same user and group file protection Unix systems have historically used. 
If the ebuild in userpriv mode can delete system files or otherwise screw
up the system, something's wrong and the system is in pretty bad shape
security-wise already, because regular users SHOULDN'T be able to mess
with the system, or with other user's files, unless the other user set it
up specifically to allow that.

The real danger therefore is turning BOTH userpriv and sandbox off, which
is why I said I couldn't recommend it, and stressed making sure things
were backed up if one tried.  Even then, it's something devs routinely say
to do, hopefully after they've taken a look at the sandbox violation log
and verified it's not going to do anything stupid.

I also said it shouldn't be a sandbox problem (everybody has it enabled
unless they've turned it off deliberately, as it's on by default, and the
fact that others have gcc installed and it's not a widely known issue
means it's not a normal sandbox problem), but that IS the obvious direct
issue in this case, or there'd not be that violation log.  I ALSO said
it's risky to turn off, particularly as the file it's trying to access
doesn't belong to the package in question (gcc) but rather to a different
vital system package, glibc.  However, as long as userpriv is on, it's not
an undue risk, and if damage occurs, there are bigger problems to worry
about.

So anyway, calm down.  userpriv is exactly the same level of system
protection normally in place, so as long as it's on, there shouldn't be
any real risk.  Only when BOTH userpriv and sandbox are off, is there a
serious risk, and I specifically said I did NOT recommend that, at least
until a dev takes a look at it and says go ahead.

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman

-- 
gentoo-amd64@gentoo.org mailing list

Re: [gentoo-amd64] Re: gcc 4.1.1 access violation

[Harry Holt]

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

Well, I'm trying with gcc 4.1.1, not 4.1.1-r1 (it's masked), but if I can't
get this to work I'll try that one.  The problem is the 3-hour compile until
the error shows up.  I'm still unclear why the ebuild postinst / qmerge does
not work - it doesn't seem to put everything in place like it should (still
have broken libs, etc.).

... HH

On 10/28/06, Hemmann, Volker Armin <volker.armin.hemmann@tu-clausthal.de>
wrote:
>
> On Saturday 28 October 2006 07:02, Duncan wrote:
>
> > You /could/ try turning sandbox off (in FEATURES).  That's a bit
> dangerous
> > by itself, but if you turn userpriv on at the same time, it should be
> > fairly safe.
>
> NO!
>
> Just no!
>
> Never ever turn of sandbox. Without sandbox, files can end everywhere in
> your
> installation, destroying stuff, make apps segfault randomly - and the
> worst,
> portage does not know about them.
>
> Never ever turn of sandbox. And never tell others to do so.
> btw
> *  sys-devel/gcc
>       Latest version available: 4.1.1-r1
>       Latest version installed: 4.1.1-r1
>
> and I have sandbox enabled. So it is not a sandbox problem. Something else
> is
> broken on his system.
> --
> gentoo-amd64@gentoo.org mailing list
>
>


-- 
Harry Holt, PMP

[-- Attachment #2: Type: text/html, Size: 1711 bytes --]

Re: [gentoo-amd64] Re: gcc 4.1.1 access violation

[Harry Holt]

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

Hmmm... Same error with 4.1.1-r1, so... sandbox issue?  Why would the
install try to mess with crt1.o?  It's  not on the list of files for GCC.


On 10/28/06, Harry Holt <harryholt@gmail.com> wrote:
>
> Well, I'm trying with gcc 4.1.1, not 4.1.1-r1 (it's masked), but if I
> can't get this to work I'll try that one.  The problem is the 3-hour compile
> until the error shows up.  I'm still unclear why the ebuild postinst /
> qmerge does not work - it doesn't seem to put everything in place like it
> should (still have broken libs, etc.).
>
> ... HH
>
> On 10/28/06, Hemmann, Volker Armin <volker.armin.hemmann@tu-clausthal.de>
> wrote:
> >
> > On Saturday 28 October 2006 07:02, Duncan wrote:
> >
> > > You /could/ try turning sandbox off (in FEATURES).  That's a bit
> > dangerous
> > > by itself, but if you turn userpriv on at the same time, it should be
> > > fairly safe.
> >
> > NO!
> >
> > Just no!
> >
> > Never ever turn of sandbox. Without sandbox, files can end everywhere in
> > your
> > installation, destroying stuff, make apps segfault randomly - and the
> > worst,
> > portage does not know about them.
> >
> > Never ever turn of sandbox. And never tell others to do so.
> > btw
> > *  sys-devel/gcc
> >       Latest version available: 4.1.1-r1
> >       Latest version installed: 4.1.1-r1
> >
> > and I have sandbox enabled. So it is not a sandbox problem. Something
> > else is
> > broken on his system.
> > --
> > gentoo-amd64@gentoo.org mailing list
> >
> >
>
>
> --
> Harry Holt, PMP




-- 
Harry Holt, PMP

[-- Attachment #2: Type: text/html, Size: 2477 bytes --]

Re: [gentoo-amd64] Re: gcc 4.1.1 access violation

[Hemmann, Volker Armin]

On Sunday 29 October 2006 04:41, Harry Holt wrote:
> Hmmm... Same error with 4.1.1-r1, so... sandbox issue?  Why would the
> install try to mess with crt1.o?  It's  not on the list of files for GCC.

I don't think so. How about opening a bug?
-- 
gentoo-amd64@gentoo.org mailing list

Re: [gentoo-amd64] Re: gcc 4.1.1 access violation

[Harry Holt]

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

Bug 153228 has been added to the database

On 10/28/06, Hemmann, Volker Armin <volker.armin.hemmann@tu-clausthal.de>
wrote:
>
> On Sunday 29 October 2006 04:41, Harry Holt wrote:
> > Hmmm... Same error with 4.1.1-r1, so... sandbox issue?  Why would the
> > install try to mess with crt1.o?  It's  not on the list of files for
> GCC.
>
> I don't think so. How about opening a bug?
> --
> gentoo-amd64@gentoo.org mailing list
>
>


-- 
Harry Holt, PMP

[-- Attachment #2: Type: text/html, Size: 859 bytes --]

[gentoo-amd64] Re: gcc 4.1.1 access violation

[Francesco Talamona]

On Saturday 28 October 2006 11:08, Hemmann, Volker Armin wrote:
> On Saturday 28 October 2006 07:02, Duncan wrote:
> > You /could/ try turning sandbox off (in FEATURES).  That's a bit
> > dangerous by itself, but if you turn userpriv on at the same time,
> > it should be fairly safe.
>
> NO!
>
> Just no!
>
> Never ever turn of sandbox. Without sandbox, files can end everywhere
> in your installation, destroying stuff, make apps segfault randomly -
> and the worst, portage does not know about them.
>
> Never ever turn of sandbox. And never tell others to do so.
> btw
> *  sys-devel/gcc
>       Latest version available: 4.1.1-r1
>       Latest version installed: 4.1.1-r1
>
> and I have sandbox enabled. So it is not a sandbox problem. Something
> else is broken on his system.

I'm running -sandbox since 09-June-2005, am I in such a danger?
Shouldn't I have experienced destructive issues in the meantime?
FEATURES="candy ccache buildpkg fixpackages -sandbox"

I can't even remember why I put -sandbox feature, it was to compile 
something I can't reckon...

ciao
	Francesco
-- 
Linux Version 2.6.18-gentoo-r1, Compiled #1 PREEMPT Wed Oct 18 22:52:55 
CEST 2006
One 1GHz AMD Athlon 64 Processor, 2GB RAM, 2003.96 Bogomips Total
aemaeth
-- 
gentoo-amd64@gentoo.org mailing list

Re: [gentoo-amd64] Re: gcc 4.1.1 access violation

[Hemmann, Volker Armin]

On Monday 30 October 2006 19:57, Francesco Talamona wrote:
> On Saturday 28 October 2006 11:08, Hemmann, Volker Armin wrote:
> > On Saturday 28 October 2006 07:02, Duncan wrote:
> > > You /could/ try turning sandbox off (in FEATURES).  That's a bit
> > > dangerous by itself, but if you turn userpriv on at the same time,
> > > it should be fairly safe.
> >
> > NO!
> >
> > Just no!
> >
> > Never ever turn of sandbox. Without sandbox, files can end everywhere
> > in your installation, destroying stuff, make apps segfault randomly -
> > and the worst, portage does not know about them.
> >
> > Never ever turn of sandbox. And never tell others to do so.
> > btw
> > *  sys-devel/gcc
> >       Latest version available: 4.1.1-r1
> >       Latest version installed: 4.1.1-r1
> >
> > and I have sandbox enabled. So it is not a sandbox problem. Something
> > else is broken on his system.
>
> I'm running -sandbox since 09-June-2005, am I in such a danger?
> Shouldn't I have experienced destructive issues in the meantime?
> FEATURES="candy ccache buildpkg fixpackages -sandbox"
>

you have experienced it. You just don't see it. Somewhere in your filesystem 
are files, that should not be there. Files, that portage does not know about 
and that won't be removed, when the package gets uninstalled.

If a package does not build with sandbox, it is broken. Open a bug.
-- 
gentoo-amd64@gentoo.org mailing list

Re: [gentoo-amd64] Re: gcc 4.1.1 access violation

[Vladimir G. Ivanovic]

On Mon, 2006-10-30 at 20:19 +0100, Hemmann, Volker Armin wrote:
> Somewhere in your filesystem 
> are files, that should not be there. Files, that portage does not know about 
> and that won't be removed, when the package gets uninstalled.

He can use "findcruft" to locate those files.

        http://forums.gentoo.org/viewtopic-t-254197.html

--- Vladimir

Vladimir G. Ivanovic <vgivanovic@comcast.net>

-- 
gentoo-amd64@gentoo.org mailing list

[gentoo-amd64] Re: gcc 4.1.1 access violation

[Francesco Talamona]

On Monday 30 October 2006 20:19, Hemmann, Volker Armin wrote:
> you have experienced it. You just don't see it. Somewhere in your
> filesystem are files, that should not be there. Files, that portage
> does not know about and that won't be removed, when the package gets
> uninstalled.
I ran findcruft some months ago, and it found some cruft around, but 
nothing really dangerous. Of course was impossible to track back every 
mud spot...

> If a package does not build with sandbox, it is broken. Open a bug.
Anyway, I just followed your advice and unset "-sandbox" fom my 
FEATURES. I really don't need it (anymore).

If anything tries to escape its sandbox should be considered potentially 
dangerous, lesson learned. 

Thanks
	Francesco
-- 
Linux Version 2.6.18-gentoo-r1, Compiled #1 PREEMPT Wed Oct 18 22:52:55 
CEST 2006
One 1.8GHz AMD Athlon 64 Processor, 2GB RAM, 3607.13 Bogomips Total
aemaeth
-- 
gentoo-amd64@gentoo.org mailing list

Re: [gentoo-amd64] Re: gcc 4.1.1 access violation

[Harry Holt]

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

Yikes!  This is still happening with gcc-4.1.1-r3.  Everything else works
fine.  I haven't had any problems with installing and updating.  Today I did
a emerge --update --deep --newuse system.  I noticed GCC at the bottom of
the list, but figured maybe it was an anomaly before.  Still no go.

I'm going to continue to just manually install the files from the sandbox
image, which oddly enough works just fine.  I seem to be the only person
having this problem!

... HH

On 10/30/06, Francesco Talamona <ti.liame@email.it> wrote:
>
> On Monday 30 October 2006 20:19, Hemmann, Volker Armin wrote:
> > you have experienced it. You just don't see it. Somewhere in your
> > filesystem are files, that should not be there. Files, that portage
> > does not know about and that won't be removed, when the package gets
> > uninstalled.
> I ran findcruft some months ago, and it found some cruft around, but
> nothing really dangerous. Of course was impossible to track back every
> mud spot...
>
> > If a package does not build with sandbox, it is broken. Open a bug.
> Anyway, I just followed your advice and unset "-sandbox" fom my
> FEATURES. I really don't need it (anymore).
>
> If anything tries to escape its sandbox should be considered potentially
> dangerous, lesson learned.
>
> Thanks
>         Francesco
> --
> Linux Version 2.6.18-gentoo-r1, Compiled #1 PREEMPT Wed Oct 18 22:52:55
> CEST 2006
> One 1.8GHz AMD Athlon 64 Processor, 2GB RAM, 3607.13 Bogomips Total
> aemaeth
> --
> gentoo-amd64@gentoo.org mailing list
>
>


-- 
Harry Holt, PMP

[-- Attachment #2: Type: text/html, Size: 2053 bytes --]