Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 135745 (gcda-sandbox) - gcc tries to write gcda files in wrong dir (read-only by sandbox).
Summary: gcc tries to write gcda files in wrong dir (read-only by sandbox).
Status: RESOLVED FIXED
Alias: gcda-sandbox
Product: Gentoo Linux
Classification: Unclassified
Component: [OLD] Core system (show other bugs)
Hardware: All Linux
: High normal (vote)
Assignee: Gentoo Toolchain Maintainers
URL:
Whiteboard:
Keywords:
: 159314 166093 170211 170945 171574 171895 174089 176294 176791 177886 185946 186422 187749 189332 189333 190529 191403 191564 191731 192698 193827 193912 195042 195299 195381 195392 195393 195413 195420 195434 195500 195581 195583 195586 195598 195650 195657 195736 195875 195879 196105 196138 196319 196901 197074 199636 201373 drbd-sandbox-problem 208006 228743 (view as bug list)
Depends on: 182361
Blocks: 134438 kernel-2.6.19
  Show dependency tree
 
Reported: 2006-06-06 03:26 UTC by Torbjörn Svensson
Modified: 2008-06-22 10:08 UTC (History)
103 users (show)

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


Attachments
return normal failure when open/fopen fail because file to read does not exist (sandbox-opennormalfail.patch,2.43 KB, patch)
2006-06-09 16:24 UTC, Kevin F. Quinn (RETIRED)
Details | Diff
same fix but for 1.2.20alpha2 (sandbox-1.2.20-opennormalfail.patch,1.99 KB, patch)
2006-07-11 13:17 UTC, Kevin F. Quinn (RETIRED)
Details | Diff
build-id-sandbox-violation.patch (build-id-sandbox-violation.patch,596 bytes, patch)
2007-10-11 15:35 UTC, Paul Bredbury
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Torbjörn Svensson 2006-06-06 03:26:06 UTC
I have used madwifi-ng snapshots newer than those in portage for a while, and recently, madwifi decided to add their own uudecode tool. As how the Makefile looks like, this isn't build until the ebuild is inside linux-mod_src_compile(). Once the linux-mod.eclass is running, the patch is changed to the kernelsource (in my case /usr/src/linux) and sandbox makes it read-only. When the uudecode.c tool is going to get compiled, gcc tries to write uudecode.gcda to ./ and sandbox screams "access violation".

With that long story telled, I have created a sample script that set's things just like the ebuild does, but still happens to be *much* smaller, you can get it here[0].

From what I have found out in #gentoo-portage at freenode, it's possible that this is a gcc bug and not a real sandbox+gcc issue. So, I ran strace of the gcc proccess, and that did print a row like this:
[pid  1223] open("file.gcda", O_RDWR)   = -1 ENOENT (No such file or directory)

This indicate that it's realy gcc's fault and not sandbox. I guess that file.gcda should be created in the same path as the file.c in my case and not in ./. 

I have successfully run this on:
* x86 - Gentoo 2006.0 with sys-devel/gcc-3.4.6-r1 sys-apps/sandbox-1.2.17
* amd64 - Gentoo 2006.0 with sys-devel/gcc-3.4.5 sys-apps/sandbox-1.2.17

[0] http://dev.azoff.se/madwifi-ng/pavel/sandbox_and_gcc.log
Comment 1 Kevin F. Quinn (RETIRED) gentoo-dev 2006-06-06 03:41:14 UTC
Some notes:

gcc attempts to open() mode O_RDWR the <source>.gcda file in the current working directory (not in the directory to which the object is written).  It does this unconditionally (toplev.c:compile_file -> coverage.c:coverage_init -> coverage.c:read_counts_file).  If it fails to open the file, then it carries on without any call graph data (used for branch prediction).

Possible ways forward:
1) gcc could be changed to stat(2) the file before opening it
2) sandbox could stat(2) the file in the open(2) wrapper, returning -1,ENOENT if stat(2) indicates the file does not exist, instead of rejecting the call.
3) gcc could be reworked to place/obtain the call graph data file from the same directory as the object file

Really there's nothing incorrect about using open(2) to test for file existence in this way.  Option 2 may be best (and simplest), since 1 and 3 would need approval upstream which may not be forthcoming.
Comment 2 SpanKY gentoo-dev 2006-06-07 04:01:15 UTC
4) add a call to `addpredict`
Comment 3 Kevin F. Quinn (RETIRED) gentoo-dev 2006-06-07 07:28:24 UTC
yeah; we suggested that on IRC but there was a reason for not doing it, but I don't recall what it was :)  Azoff, please elaborate...
Comment 4 Torbjörn Svensson 2006-06-07 09:07:43 UTC
Sorry, I can't recall either. I did just reread the log from out conversation Quinn, but I can't find anything about some "addpredict". 
Comment 5 Kevin F. Quinn (RETIRED) gentoo-dev 2006-06-07 11:34:21 UTC
(In reply to comment #4)
> but I can't find anything about some "addpredict".

Sorry - addpredict adds its parameters to SANDBOX_WRITE, which is what we spoke about:

09:57 < kevquinn> I guess you neeed to add the current directory to the list of writable directories.
09:57 < Azoff> yes, but that's the point. I can't do that
09:58 < Azoff> as I said before, this is just a snipset of how to build madwifi-ng, and that's done from the kernel source (usally /usr/src/linux)
09:58 < Azoff> and, atleast I do not want the kernel-tree to be rw when compiling modules
Comment 6 Torbjörn Svensson 2006-06-07 12:04:20 UTC
(In reply to comment #5)
> Sorry - addpredict adds its parameters to SANDBOX_WRITE, which is what we spoke
> about:

Ahh, yes. =)
The reason is that you do not wanna make modules able to write the the kernel tree (in this case). I think that the best way is to use the stat(2) call from comment #2 to fix this.
Comment 7 SpanKY gentoo-dev 2006-06-07 14:12:05 UTC
uhh, no it doesnt ... otherwise addpredict would be the samething as addwrite

addpredict() {
    export SANDBOX_PREDICT="$SANDBOX_PREDICT:$1"
}
Comment 8 Torbjörn Svensson 2006-06-09 09:09:15 UTC
Oki, I tried to add it to the ebuild and it works I think. 
This is realy just a work arround as the bug is still there, how do you guys think we should move forward?
Comment 9 SpanKY gentoo-dev 2006-06-09 12:59:53 UTC
that depends on how complex we want to get with sandbox

we could change the open() wrapper to allow the open() through and if it succedded but violates sandbox, we throw an error and close the fd ... but if open() returned -1, then sandbox doesnt throw a violation and it too returns a -1

might get tricky though when it comes to open() working, creating a file somewhere it shouldnt have, and then sandbox throwing an error ...
Comment 10 Kevin F. Quinn (RETIRED) gentoo-dev 2006-06-09 16:20:22 UTC
yeah; I don't think we should let open() through like that, even if sandbox immediately kills the caller after the open() call.  It is likely to affect the live filesystem, which is precisely what sandbox is trying to protect.  I think if we modify sandbox, it should be to use permitted operations (e.g. stat(2))to test whether the controlled operations would fail

I suggest we deal with situations one by one as they arise, rather than try to handle all possible ways the various controlled operations may fail in ways that applications find useful.  Since this case is using the failure of open when called with O_RDWR (i.e. without O_CREAT) as a shortcut to existence testing then this is what we should test for.
Comment 11 Kevin F. Quinn (RETIRED) gentoo-dev 2006-06-09 16:24:08 UTC
Created attachment 88797 [details, diff]
return normal failure when open/fopen fail because file to read does not exist

How's this, for example.

For open() & open64(), returns -1 if the flags do not include O_CREAT and stat() indicates file does not exist.

For fopen() & fopen64(), returns NULL if the mode starts 'r' and stat() indicates file does not exist.

Leaves errno as that set by stat, since this is what the open calls do.
Comment 12 SpanKY gentoo-dev 2006-06-10 02:35:46 UTC
checking mode[0] isnt reliable ... using something like "wr" is valid, so you'll need to do like 'strchr()' for 'r'

otherwise looks good, thanks
Comment 13 Kevin F. Quinn (RETIRED) gentoo-dev 2006-06-10 03:46:39 UTC
I read fopen(2) to imply only one of the options could be present (or at least only the option at the beginning of the string is effective), and that by "additional characters may follow" it means the optional 'b' is effective and any other text is ignored.

Actually; just done some tests.  "rw" behaves as if you had done just "r" (i.e. file not created, if exists it can't be written).  "wr" behaves as if you had done just "w" (i.e. file created, can't be read).  So I think my reading of the man page is correct - only the first sequence is significant.
Comment 14 SpanKY gentoo-dev 2006-06-10 04:06:25 UTC
agreed, ignore my previous comment :)
Comment 15 Henrik Brix Andersen 2006-06-21 15:39:13 UTC
FYI, I've attached a simple workaround to bug #134438. It abuses the that .gcda files are opened in the same dir as .o files. This is, of course, not to be considered a permanent solution.
Comment 16 Kevin F. Quinn (RETIRED) gentoo-dev 2006-07-11 13:17:32 UTC
Created attachment 91504 [details, diff]
same fix but for 1.2.20alpha2

Actually the patch is pretty much identical, apart from changing src/libsandbox/wrappers.c instead of src/libsandbox.c :)
Comment 17 Martin Schlemmer (RETIRED) gentoo-dev 2006-07-12 09:59:21 UTC
Committed to svn. Will see if I get time to add it to ~ sandbox.
Comment 18 SpanKY gentoo-dev 2007-01-03 01:48:27 UTC
*** Bug 159314 has been marked as a duplicate of this bug. ***
Comment 19 Thomas Sachau gentoo-dev 2007-01-03 19:01:47 UTC
The last comment is 6 month ago. Is anyone working on this?
Comment 20 Jakub Moc (RETIRED) gentoo-dev 2007-02-09 16:38:52 UTC
*** Bug 166093 has been marked as a duplicate of this bug. ***
Comment 21 boris64 2007-02-09 18:32:29 UTC
Hi, i'm having the same problem(s) as seen in this bug -> https://bugs.gentoo.org/show_bug.cgi?id=166093 (marked as duplicate)
since kernel >2.6.18.

Actually i can't emerge any(!) external module ebuild (nvidia-drivers/lirc/vmware-modules/gspcav1/truecrypt) anymore because of this.
So Sandbox seems to be pretty unusable for me right now :/

Check the link for an $(emerge info) ;)
-> [url]http://boris64.net/files/emergeinfo.txt[/url]
Comment 22 Jeffrey Bridge 2007-02-27 19:48:22 UTC
Hi, I'm running into this same problem trying to emerge nvidia-drivers-1.0.9746 with vanilla 2.6.20.1 on amd64. Also vmware-modules.
Comment 23 Jakub Moc (RETIRED) gentoo-dev 2007-03-10 08:36:18 UTC
*** Bug 170211 has been marked as a duplicate of this bug. ***
Comment 24 Jakub Moc (RETIRED) gentoo-dev 2007-03-14 21:03:23 UTC
*** Bug 170945 has been marked as a duplicate of this bug. ***
Comment 25 Jakub Moc (RETIRED) gentoo-dev 2007-03-20 15:13:27 UTC
*** Bug 171574 has been marked as a duplicate of this bug. ***
Comment 26 Stratos Psomadakis (RETIRED) gentoo-dev 2007-03-20 18:23:26 UTC
i have the same problem with nvidia-drivers-1.0.9746 and gentoo-sources 2.6.20-r3(*** Bug 171574 has been marked as a duplicate of this bug. ***)...
the only way to compile nvidia-drivers is with FEATURES="-sandbox"... :/
with 2.6.19 gentoo-sources i had no problems(why? :/)
Comment 27 D3LLF 2007-03-21 08:36:55 UTC
Some kind of workaround for this can be using ebuild /usr/portage{package}.ebuild merge (somtimes must be run twice to get the effect).
Comment 28 Jakub Moc (RETIRED) gentoo-dev 2007-03-23 17:32:36 UTC
*** Bug 171895 has been marked as a duplicate of this bug. ***
Comment 29 Jakub Moc (RETIRED) gentoo-dev 2007-04-10 21:15:13 UTC
*** Bug 174089 has been marked as a duplicate of this bug. ***
Comment 30 Łukasz Damentko (RETIRED) gentoo-dev 2007-04-28 11:58:53 UTC
*** Bug 176294 has been marked as a duplicate of this bug. ***
Comment 31 Jakub Moc (RETIRED) gentoo-dev 2007-05-02 11:23:31 UTC
*** Bug 176791 has been marked as a duplicate of this bug. ***
Comment 32 Jakub Moc (RETIRED) gentoo-dev 2007-05-10 06:01:24 UTC
*** Bug 177886 has been marked as a duplicate of this bug. ***
Comment 33 Thomas Sachau gentoo-dev 2007-07-10 16:29:49 UTC
Still having this problem with gcc-4.1.2, sandbox-1.2.18.1 and stable(!) gentoo-sources-2.6.20-r8.

Is anyone still working on this problem or will i have to stay with <gentoo-sources-2.6.19 on my amd64 system forever?
Comment 34 Arfrever Frehtes Taifersar Arahesis (RETIRED) gentoo-dev 2007-07-10 18:20:58 UTC
(In reply to comment #33)
> Still having this problem with gcc-4.1.2, sandbox-1.2.18.1 and stable(!)
> gentoo-sources-2.6.20-r8.
> 
> Is anyone still working on this problem or will i have to stay with
> <gentoo-sources-2.6.19 on my amd64 system forever?

You can work around it by using:
FEATURES="-sandbox" emerge -1 package
Comment 35 Martin Väth 2007-07-10 19:49:24 UTC
(In reply to comment #34)
> You can work around it [...]

But as you say, it is only a workaround.
The attached patch works. It is now more than a year old.
Is there a reason that it is not included into sandbox yet?
Actually, it seems that the latest (masked) sandbox version is almost that old, too.

Maybe sandbox development was completely abandoned?
Comment 36 real name 2007-07-11 17:51:07 UTC
*bump*

I'm having the same problem, after I download an experimental wifi driver (rt2x00). Steps to reproduce the problem I'm having:

$ USE="curl" emerge git
$ emerge cogito
$ cg clone http://git.serialmonkey.com/rt2x00.git/
$ # the repository download is about 100 Mb
$ cd rt2x00
$ # at this point, I'm in a complete linux kernel.
$ make menuconfig
$ make && sudo make modules_install
$ sudo telinit 6
$ # system reboots
$ rm -f /usr/src/linux && ln -s <somewhere>/rt2x00 /usr/src/linux
$ # both of these emerge commands fail with the same problem:
$ emerge nvidia-drivers
Calculating dependencies... done!
>>> Verifying ebuild Manifests...

>>> Emerging (1 of 1) x11-drivers/nvidia-drivers-1.0.9755-r1 to /
   ... snip ...
 * Found kernel source directory:
 *     /usr/src/linux
 * Found sources for kernel version:
 *     2.6.22-rc6-ga5b67c9e
   ... snip ...
NVIDIA: left KBUILD.
>>> Source compiled.
--------------------------- ACCESS VIOLATION SUMMARY ---------------------------
LOG FILE = "/var/log/sandbox/sandbox-x11-drivers_-_nvidia-drivers-1.0.9755-r1-29953.log"

open_wr:   /usr/src/rt73/rt2x00/-.gcda
open_wr:   /usr/src/rt73/rt2x00/-.gcda
--------------------------------------------------------------------------------
$
$ emerge sys-fs/fuse
Calculating dependencies... done!
>>> Verifying ebuild Manifests...

>>> Emerging (1 of 1) sys-fs/fuse-2.7.0 to /
   ... snip ...
 * Found kernel source directory:
 *     /usr/src/linux
 * Found sources for kernel version:
 *     2.6.22-rc6-ga5b67c9e
   ... snip ...
make[1]: Leaving directory `/usr/src/rt73/rt2x00'
>>> Source compiled.
--------------------------- ACCESS VIOLATION SUMMARY ---------------------------
LOG FILE = "/var/log/sandbox/sandbox-sys-fs_-_fuse-2.7.0-31521.log"

open_wr:   /usr/src/rt73/rt2x00/-.gcda
open_wr:   /usr/src/rt73/rt2x00/-.gcda
--------------------------------------------------------------------------------
$


The workaround works: FEATURES="-sandbox" emerge <ebuild>

I have compiled the following kernels that I downloaded from www.kernel.org, and none of them have a problem:

linux-2.6.21
linux-2.6.22-rc1
linux-2.6.22-rc2
linux-2.6.22-rc3
linux-2.6.22-rc4
linux-2.6.22-rc5
linux-2.6.22-rc6
linux-2.6.22-rc7
linux-2.6.22

I'm not sure what the rt2x00 kernel does to trigger gcc's bad behavior, so that it looks for -.gcda
Comment 37 Steve Arnold gentoo-dev 2007-07-13 14:16:05 UTC
This is still a problem building a lirc, even if LIRC_DEVICES is unset (ie, not building any kernel drivers).  Seems like it needs a real fix...
Comment 38 Jakub Moc (RETIRED) gentoo-dev 2007-07-20 06:43:16 UTC
*** Bug 185946 has been marked as a duplicate of this bug. ***
Comment 39 Jakub Moc (RETIRED) gentoo-dev 2007-07-24 06:37:44 UTC
*** Bug 186422 has been marked as a duplicate of this bug. ***
Comment 40 Neal McConachie 2007-07-27 01:34:13 UTC
This is still an issue with gentoo-sources-2.6.20-r8 and nvidia-drivers on amd64, with gcc-4.1.2

feel free to let me know if I can try to provide any helpful information
Comment 41 Christian Schmidt 2007-07-30 13:09:31 UTC
Some more of the same (gcc-4.2.0, ~amd64)
Most of these don't compile anyway, but still:

x11-drivers/ati-drivers-8.38.6 (not in portage, but at least halfway working on 2.6.22)
x11-drivers/nvidia-drivers-100.14.11
net-wireless/madwifi-ng-99999 (CVS, but at least supports my card, and the only one that actually builds with 2.6.23rc :))
app-emulation/vmware-modules-1.0.0.16
app-emulation/virtualbox-modules-1.4.0
app-crypt/truecrypt-4.3a

All of the above produce sandbox violations on 2.6.23-rc1-mm1:
open_wr:   /usr/src/linux-2.6.23-rc1-mm1/null.gcda 
but no problems with the same gcc-4.2.0 and vanilla-2.6.22.1.
There might be an upcoming problem, just so you know.
Comment 42 Craig Andrews gentoo-dev 2007-07-30 14:48:42 UTC
I get this error on my ~amd64 system with gentoo-sources-2.6.22-r1/r2, but only when I have selected the stack smashing protection kernel configuration option. If that is unselected, everything compile fine.
Comment 43 Jakub Moc (RETIRED) gentoo-dev 2007-08-05 05:50:03 UTC
*** Bug 187749 has been marked as a duplicate of this bug. ***
Comment 44 Jakub Moc (RETIRED) gentoo-dev 2007-08-18 09:29:18 UTC
*** Bug 189332 has been marked as a duplicate of this bug. ***
Comment 45 Jakub Moc (RETIRED) gentoo-dev 2007-08-18 09:34:21 UTC
*** Bug 189333 has been marked as a duplicate of this bug. ***
Comment 46 David Pyke 2007-08-24 14:44:25 UTC
I'll add qc-usb-messenger to the list of modules that error out.

open_wr:   /usr/src/linux-2.6.22-gentoo-r4/-.gcda
Comment 47 Jakub Moc (RETIRED) gentoo-dev 2007-08-28 15:21:55 UTC
*** Bug 190529 has been marked as a duplicate of this bug. ***
Comment 48 Gilles Dartiguelongue gentoo-dev 2007-09-04 12:36:53 UTC
I'm adding app-emulation/kqemu to the list.
I'll read on/test stuff later.
Comment 49 Jakub Moc (RETIRED) gentoo-dev 2007-09-05 17:55:20 UTC
*** Bug 191403 has been marked as a duplicate of this bug. ***
Comment 50 SpanKY gentoo-dev 2007-09-07 07:11:20 UTC
*** Bug 191564 has been marked as a duplicate of this bug. ***
Comment 51 Jakub Moc (RETIRED) gentoo-dev 2007-09-08 20:42:49 UTC
*** Bug 191731 has been marked as a duplicate of this bug. ***
Comment 52 Jakub Moc (RETIRED) gentoo-dev 2007-09-16 15:17:46 UTC
*** Bug 192698 has been marked as a duplicate of this bug. ***
Comment 53 Jakub Moc (RETIRED) gentoo-dev 2007-09-26 06:09:57 UTC
*** Bug 193827 has been marked as a duplicate of this bug. ***
Comment 54 Jakub Moc (RETIRED) gentoo-dev 2007-09-26 21:43:56 UTC
*** Bug 193912 has been marked as a duplicate of this bug. ***
Comment 55 Robert A. 2007-09-29 13:33:06 UTC
(In reply to comment #41)
> There might be an upcoming problem, just so you know.

Definitely..

Same problem here for:
tp_smapi
virtualbox-modules
kqemu
ipw3945
vmware-modules
alsa-driver

using
vanilla-2.6.23-rc8
gcc-4.1.2
sandbox-1.2.17

the error does not occure with gentoo-sources-2.6.22-r8
Comment 56 Jakub Moc (RETIRED) gentoo-dev 2007-10-08 07:03:10 UTC
*** Bug 195042 has been marked as a duplicate of this bug. ***
Comment 57 Jakub Moc (RETIRED) gentoo-dev 2007-10-08 19:22:12 UTC
*** Bug 195137 has been marked as a duplicate of this bug. ***
Comment 58 Bernie Hackett 2007-10-08 20:15:22 UTC
The same problem exists with net-fs/openafs-kernel-1.4.4_p20070724-r2

I just merged it using FEATURES="-sandbox" which of course defeats the
purpose of the sandbox in the first place...
Comment 59 Jakub Moc (RETIRED) gentoo-dev 2007-10-10 06:17:44 UTC
*** Bug 195299 has been marked as a duplicate of this bug. ***
Comment 60 Jakub Moc (RETIRED) gentoo-dev 2007-10-10 07:02:40 UTC
Eh, so??? Anyone to pick up sandbox maintenance? Or, are we going to patch gcc? This bug has been sitting here for 16 months, getting swamped by duplicates.
Comment 61 Sven 2007-10-10 07:56:41 UTC
this should block bug 195298
Comment 62 Jakub Moc (RETIRED) gentoo-dev 2007-10-10 07:59:29 UTC
(In reply to comment #61)
> this should block bug 195298

No it really shouldn't, as you could have noticed, this issue has existed ages before 2.6.23

Comment 63 Sven 2007-10-10 08:08:44 UTC
> > this should block bug 195298
> 
> No it really shouldn't, as you could have noticed, this issue has existed ages
> before 2.6.23

yes, sure, but this bug has to be resolved, before 2.6.23 can go stable.
Comment 64 Jakub Moc (RETIRED) gentoo-dev 2007-10-10 08:15:52 UTC
(In reply to comment #63)
> yes, sure, but this bug has to be resolved, before 2.6.23 can go stable.

This bug has nothing to do with 2.6.23 specifically, has existed ages before 2.6.23 and doesn't block 2.6.23 stabilization in any way. It's a gcc/sandbox issue as explained above. Now please, keep the comments on-topic.
Comment 65 Jakub Moc (RETIRED) gentoo-dev 2007-10-10 16:34:14 UTC
*** Bug 195393 has been marked as a duplicate of this bug. ***
Comment 66 Jakub Moc (RETIRED) gentoo-dev 2007-10-10 16:34:44 UTC
*** Bug 195392 has been marked as a duplicate of this bug. ***
Comment 67 Jakub Moc (RETIRED) gentoo-dev 2007-10-10 16:35:46 UTC
*** Bug 195381 has been marked as a duplicate of this bug. ***
Comment 68 Chris Smith 2007-10-10 17:38:42 UTC
currently (w/gentoo-sources-2.6.23 in case this is relavent) prevents vlc emerge as well as nvidia-drivers and alsa-drivers
Comment 69 Chris Smith 2007-10-10 17:40:24 UTC
(In reply to comment #68)
> currently (w/gentoo-sources-2.6.23 in case this is relavent) prevents vlc
> emerge as well as nvidia-drivers and alsa-drivers
> 

Actually vlc may be a different sandbox problem:

>>> Source compiled.
--------------------------- ACCESS VIOLATION SUMMARY ---------------------------
LOG FILE = "/var/log/sandbox/sandbox-media-video_-_vlc-0.9.0_alpha20071009-6095.log"

open_wr:   /var/cache/samba/gencache.tdb
--------------------------------------------------------------------------------
Comment 70 Jakub Moc (RETIRED) gentoo-dev 2007-10-10 17:43:11 UTC
(In reply to comment #69)
> open_wr:   /var/cache/samba/gencache.tdb

Unrelated, Bug 121573. 
Comment 71 Jakub Moc (RETIRED) gentoo-dev 2007-10-10 18:36:02 UTC
*** Bug 195413 has been marked as a duplicate of this bug. ***
Comment 72 Jakub Moc (RETIRED) gentoo-dev 2007-10-10 19:12:45 UTC
*** Bug 195420 has been marked as a duplicate of this bug. ***
Comment 73 Graham Murray 2007-10-10 19:40:33 UTC
(In reply to comment #64)
> This bug has nothing to do with 2.6.23 specifically, has existed ages before
> 2.6.23 and doesn't block 2.6.23 stabilization in any way. 

yet it seems to be manifesting when upgrading to 2.6.23 when the same ebuilds build fine with earlier versions. Therefore if it is not resolved before 2.6.23 goes stable, there will be lots more duplicate bugs and unhappy users of the stable tree. Those of us running ~arch expect problems from time to time, but users of the stable tree do (and should) not.

Comment 74 Bernie Hackett 2007-10-10 20:13:31 UTC
(In reply to comment #73)
>
> yet it seems to be manifesting when upgrading to 2.6.23 when the same ebuilds
> build fine with earlier versions. 
> 

I first started seeing this with gentoo-sources-2.6.22-r8. It got worse when I upgraded to gcc-4.2.1 from 4.2.0.

Comment 75 Jakub Moc (RETIRED) gentoo-dev 2007-10-10 22:43:31 UTC
*** Bug 195434 has been marked as a duplicate of this bug. ***
Comment 76 Daniel Drake (RETIRED) gentoo-dev 2007-10-11 07:52:09 UTC
Can someone else who believes they have started getting this problem please confirm?

Please do a thorough test, i.e. go into a 2.6.22 directory, back up your .config, run "make mrproper", put .config back, recompile kernel.

Then: KERNEL_DIR=/usr/src/linux-2.6.22-whatever emerge some-module

Does the sandbox error appear?

Then repeat for 2.6.23 and see if the error appears there...
Comment 77 Daniel Drake (RETIRED) gentoo-dev 2007-10-11 07:53:07 UTC
(In reply to comment #76)
> Can someone else who believes they have started getting this problem please
> confirm?

should have read "who believes they have started getting this problem *since 2.6.23* please confirm"... I'm interesting in the 2.6.23 regression case, which I don't think exists.
Comment 78 Ortwin Glueck 2007-10-11 07:56:04 UTC
I can confirm that I am only seeing the problem with 2.6.23. I have 3 modules outside the tree that I emerge regularly and all of them fail with 2.6.23 while all is fine with 2.6.22: ati-drivers, ndiswrapper, linux-uvc.
Comment 79 Daniel Drake (RETIRED) gentoo-dev 2007-10-11 08:13:31 UTC
Did you reconfirm the 2.6.22 failures after seeing the 2.6.23 ones? Did you try the more exhaustive tests from above where you actually recompile your whole kernel before trying to reproduce?
Comment 80 Panagiotis Christopoulos (RETIRED) gentoo-dev 2007-10-11 09:48:44 UTC
(In reply to comment #79)
> Did you reconfirm the 2.6.22 failures after seeing the 2.6.23 ones? Did you try
> the more exhaustive tests from above where you actually recompile your whole
> kernel before trying to reproduce?
> 
 
I did the tests as you said above, first with 2.6.22-gentoo-r8 and then with 2.6.23-gentoo, (make mrproper && make etc...),recompiled both kernels, and tested by emerging svgalib first with KERNEL_DIR=/usr/src/linux/linux-2.6.22-gentoo-r8, and then again, with KERNEL_DIR=/usr/src/linux/linux-2.6.23-gentoo.

with 2.6.22, everything was fine, but I had sandbox violations with 2.6.23:
--------------------------- ACCESS VIOLATION SUMMARY ---------------------------
LOG FILE = "/var/log/sandbox/sandbox-media-libs_-_svgalib-1.9.25-25339.log"

open_wr:   /usr/src/linux-2.6.23-gentoo/null.gcda
open_wr:   /usr/src/linux-2.6.23-gentoo/null.gcda
open_wr:   /usr/src/linux-2.6.23-gentoo/null.gcda
open_wr:   /usr/src/linux-2.6.23-gentoo/null.gcda
open_wr:   /usr/src/linux-2.6.23-gentoo/null.gcda
--------------------------------------------------------------------------------

I don't know if I helped, but I gave a try,

Panagiotis(pchrist)
Comment 81 Panagiotis Christopoulos (RETIRED) gentoo-dev 2007-10-11 09:52:53 UTC
<<KERNEL_DIR=/usr/src/linux/linux-2.6.22-gentoo-r8, and then again, with
<<KERNEL_DIR=/usr/src/linux/linux-2.6.23-gentoo

>>KERNEL_DIR=/usr/src/linux-2.6.22-gentoo-r8, and then again, with
>>KERNEL_DIR=/usr/src/linux-2.6.23-gentoo

*
Comment 82 Robert A. 2007-10-11 10:12:07 UTC
I first thought its a 2.6.23 related bug, but I get this error:

(In reply to comment #55)
> Same problem here for:
> tp_smapi
> virtualbox-modules
> kqemu
> ipw3945
> vmware-modules
> alsa-driver
> 
> using
> vanilla-2.6.23-rc8
> gcc-4.1.2
> sandbox-1.2.17

even with vanilla-sources-2.6.20.20 and gentoo-sources-2.6.22-r8.
Comment 83 Vasilis Lourdas 2007-10-11 13:37:39 UTC
Same situation with x11-drivers/ati-drivers-8.40.4 and gentoo-sources-2.6.23.


  LD [M]  /var/tmp/portage/x11-drivers/ati-drivers-8.40.4/work/common/lib/modules/fglrx/build_mod/2.6.x/fglrx.o
  Building modules, stage 2.
  MODPOST 1 modules
  CC      /var/tmp/portage/x11-drivers/ati-drivers-8.40.4/work/common/lib/modules/fglrx/build_mod/2.6.x/fglrx.mod.o
  LD [M]  /var/tmp/portage/x11-drivers/ati-drivers-8.40.4/work/common/lib/modules/fglrx/build_mod/2.6.x/fglrx.ko
make[1]: Leaving directory `/usr/src/linux-2.6.23-gentoo'
 * Building fgl_glxgears
 * Building fglrx_gamma lib
 * Building fglrx_gamma util
>>> Source compiled.
--------------------------- ACCESS VIOLATION SUMMARY ---------------------------
LOG FILE = "/var/log/sandbox/sandbox-x11-drivers_-_ati-drivers-8.40.4-14944.log"

open_wr:   /usr/src/linux-2.6.23-gentoo/null.gcda
open_wr:   /usr/src/linux-2.6.23-gentoo/null.gcda
open_wr:   /usr/src/linux-2.6.23-gentoo/null.gcda
open_wr:   /usr/src/linux-2.6.23-gentoo/null.gcda
open_wr:   /usr/src/linux-2.6.23-gentoo/null.gcda
--------------------------------------------------------------------------------
Comment 84 Jakub Moc (RETIRED) gentoo-dev 2007-10-11 14:03:49 UTC
*** Bug 195500 has been marked as a duplicate of this bug. ***
Comment 85 Jakub Moc (RETIRED) gentoo-dev 2007-10-11 14:09:41 UTC
Please, please stop sticking 'me too!111!' comments here. If you can't provide info requested in Comment #77 or anything beyond 'me too' then there's absolutely no need to comment here, the bug is already noisy enough.
Comment 86 Sebastian 2007-10-11 15:03:27 UTC
I can't speak about the gcc related sandbox violations, but the ones due to changes between kernel 2.6.22 and 2.6.23(-rc1) apparently stem from kernel git commit 18991197b4b588255ccabf472ebc84db7b66a19c, at least that's what a git bisection revealed. I used "emerge lirc" to find the good and bad revisions:

commit 18991197b4b588255ccabf472ebc84db7b66a19c
Author: Roland McGrath <roland@redhat.com>
Date:   Thu Jul 19 01:48:40 2007 -0700

    Use --build-id ld option

    This change passes the --build-id when linking the kernel and when linking
    modules, if ld supports it.  This is a new GNU ld option that synthesizes an
    ELF note section inside the read-only data.  The note in this section contains
    unique identifying bits called the "build ID", which are generated so as to be
    different for any two linked ELF files that aren't identical.  The build ID
    can be recovered from stripped files, memory dumps, etc.  and used to look up
    the original program built, locate debuginfo or other details or history
    associated with it.  For normal program linking, the compiler passes
    --build-id to ld by default, but the option is needed when using ld directly
    as we do.

    Signed-off-by: Roland McGrath <roland@redhat.com>
    Cc: Andi Kleen <ak@suse.de>
    Cc: Paul Mackerras <paulus@samba.org>
    Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
    Cc: Richard Henderson <rth@twiddle.net>
    Cc: Ivan Kokshaysky <ink@jurassic.park.msu.ru>
    Cc: Martin Schwidefsky <schwidefsky@de.ibm.com>
    Cc: Heiko Carstens <heiko.carstens@de.ibm.com>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>

:100644 100644 ddbfcac299c1c587c2e9f5d172bfb3e052b12118 eccb03b88b8d6f88c59540d93bd6c1bb68e117f6 M      Makefile

Reversing this commit makes the sandbox violations go away.

Regards
Sebastian
Comment 87 Renato Caldas 2007-10-11 15:15:28 UTC
I've been getting violations in every external kernel module I emerge since before 2.6.22 (I'm not sure from which version). I suspect these "2.6.23 blocker issues" were somewhat exclusive to x86_64 up until now.

Is there any x86_64 user who _ONLY_ started getting this issue since 2.6.23? This would blow up my theory.. :P
Comment 88 Paul Bredbury 2007-10-11 15:35:44 UTC
Created attachment 133144 [details, diff]
build-id-sandbox-violation.patch

Fixes my x86 git-sources-2.6.23_rc9-r6 kernel module sandbox violations. Thanks to comment #86.
Comment 89 Rafael 2007-10-11 16:55:52 UTC
(In reply to comment #87)
> I've been getting violations in every external kernel module I emerge since
> before 2.6.22 (I'm not sure from which version). I suspect these "2.6.23
> blocker issues" were somewhat exclusive to x86_64 up until now.
> 
> Is there any x86_64 user who _ONLY_ started getting this issue since 2.6.23?
> This would blow up my theory.. :P
> 

I do! 
I can build the nvidia-drivers-100.14.19 package without acces violations if my /usr/src/linux symlink points to linux-2.6.22-gentoo-r8. But when I change the link to point to linux-2.6.23-gentoo, then acces violation happens when I try to build nvidia-drivers.
Comment 90 Pacho Ramos gentoo-dev 2007-10-11 17:02:15 UTC
I can build external modules in 2.6.22, but no one in 2.6.23
Comment 91 Dan Coats 2007-10-11 17:49:53 UTC
same here, I only have this problem on "any of my boxes" with 2.6.23, using any other kernel this issue is non existent for me.
Comment 92 Renato Caldas 2007-10-11 18:12:03 UTC
Ok, I got the idea, my theory is wrong (no need for more postings).

So maybe there's something buggy in my config. I'll check the patch and see if it helps, and maybe recheck my config.
Comment 93 Vasilis Lourdas 2007-10-11 18:25:11 UTC
(In reply to comment #85)
> Please, please stop sticking 'me too!111!' comments here. If you can't provide
> info requested in Comment #77 or anything beyond 'me too' then there's
> absolutely no need to comment here, the bug is already noisy enough.

I'm sorry to say that, but sometimes you developers are too jumpy on us simple users. You know it takes us some time to come here, login and fill in a new bug report or even post a comment. And I can't go through a bug report with its 80+ comments, just to try something that was written in a few comments back. We thank you for all the good work that you put in the Gentoo project, but at least you could show us a bit of respect for our time we spend here.

Just for the record, the sandbox issue came up after upgrading to gentoo-sources-2.6.23 and after re-emerging ati-drivers.

Thanks.
Comment 94 Grzegorz {NineX} Krzystek 2007-10-11 19:18:03 UTC
(In reply to comment #89)
> (In reply to comment #87)
> > I've been getting violations in every external kernel module I emerge since
> > before 2.6.22 (I'm not sure from which version). I suspect these "2.6.23
> > blocker issues" were somewhat exclusive to x86_64 up until now.
> > 
> > Is there any x86_64 user who _ONLY_ started getting this issue since 2.6.23?
> > This would blow up my theory.. :P
> > 
> 
> I do! 
> I can build the nvidia-drivers-100.14.19 package without acces violations if my
> /usr/src/linux symlink points to linux-2.6.22-gentoo-r8. But when I change the
> link to point to linux-2.6.23-gentoo, then acces violation happens when I try
> to build nvidia-drivers.
> 
witch gcc version????
i have access voliations on 2.6.22 and 2.6.23 kernels with gcc 4.2.2, and 4.2.1 on amd64

Comment 95 Daniel Drake (RETIRED) gentoo-dev 2007-10-11 19:51:13 UTC
(In reply to comment #93)
> I'm sorry to say that, but sometimes you developers are too jumpy on us simple
> users. You know it takes us some time to come here, login and fill in a new bug

Sorry if it sounded a little rude. The problem is that these messages which aren't really any use to us hide any more important messages in the noise.

At this point, we don't need any more testing, there's enough evidence to show that 2.6.23 does *introduce* it for some users, but others have had it for ages, and theres even an explanation for the 2.6.23 introduction thanks to Sebastian.

We just need some time to work on a proper fix.
Comment 96 Zac Medico gentoo-dev 2007-10-12 06:39:01 UTC
*** Bug 195583 has been marked as a duplicate of this bug. ***
Comment 97 Jakub Moc (RETIRED) gentoo-dev 2007-10-12 07:31:49 UTC
*** Bug 195586 has been marked as a duplicate of this bug. ***
Comment 98 Jakub Moc (RETIRED) gentoo-dev 2007-10-12 07:34:25 UTC
*** Bug 195581 has been marked as a duplicate of this bug. ***
Comment 99 Jakub Moc (RETIRED) gentoo-dev 2007-10-12 09:32:56 UTC
*** Bug 195598 has been marked as a duplicate of this bug. ***
Comment 100 Jan Mentzel 2007-10-12 18:35:46 UTC
this is not only a "me too" ...

I need to run 2.6.23 instead of 2.6.22 because of constant lockups (up to several times a day) related to  http://bugzilla.kernel.org/show_bug.cgi?id=8757

My question: can we use something like the --build-id thing mentioned in #86 to temporaryly get rid of the problem? If 'yes' how?
Comment 101 georgi 2007-10-12 18:48:17 UTC
> My question: can we use something like the --build-id thing mentioned in #86 to
> temporaryly get rid of the problem? If 'yes' how?

Emerging kernel modules with FEATURES="-sandbox" emerge... might be the temporary workaround you're looking for.

\gc
Comment 102 Ortwin Glueck 2007-10-12 18:55:43 UTC
To be precise, it's:

FEATURES="-sandbox -usersandbox" emerge ...
Comment 103 Paul Bredbury 2007-10-12 18:56:49 UTC
Use the *forums* to ask such questions.

See http://forums.gentoo.org/viewtopic-t-597887.html
Comment 104 Jakub Moc (RETIRED) gentoo-dev 2007-10-12 19:20:32 UTC
*** Bug 195650 has been marked as a duplicate of this bug. ***
Comment 105 Marcos Sartori 2007-10-12 20:25:40 UTC
*** Bug 195657 has been marked as a duplicate of this bug. ***
Comment 106 Jakub Moc (RETIRED) gentoo-dev 2007-10-13 22:05:01 UTC
*** Bug 195736 has been marked as a duplicate of this bug. ***
Comment 107 Russell Knighton 2007-10-14 18:07:39 UTC
Daniel,

> who believes they have started getting this problem *since
> 2.6.23* please confirm"... I'm interesting in the 2.6.23 regression case, 
> which I don't think exists.

I can confirm I have only started to receive this issue since updating to 2.6.23. I switched symlinks back to 2.6.22-r8, and modules compile fine again.

emerge info:-
Portage 2.1.3.12 (default-linux/x86/2006.1, gcc-4.2.2, glibc-2.6.1-r0, 2.6.22-gentoo-r8 i686)
=================================================================
System uname: 2.6.22-gentoo-r8 i686 AMD Sempron(tm)
Timestamp of tree: Sun, 14 Oct 2007 10:00:01 +0000
distcc 2.18.3 i686-pc-linux-gnu (protocols 1 and 2) (default port 3632) [disabled]
ccache version 2.4 [enabled]
app-shells/bash:     3.2_p17-r1
dev-java/java-config: 1.3.7, 2.1.1
dev-lang/python:     2.5.1-r2
dev-python/pycrypto: 2.0.1-r6
dev-util/ccache:     2.4-r7
sys-apps/baselayout: 1.12.10-r5
sys-apps/sandbox:    1.2.18.1
sys-devel/autoconf:  2.13, 2.61-r1
sys-devel/automake:  1.4_p6, 1.5, 1.6.3, 1.7.9-r1, 1.8.5-r3, 1.9.6-r2, 1.10
sys-devel/binutils:  2.18-r1
sys-devel/gcc-config: 1.4.0-r4
sys-devel/libtool:   1.5.24
virtual/os-headers:  2.6.23
ACCEPT_KEYWORDS="x86 ~x86"
CBUILD="i686-pc-linux-gnu"
CFLAGS="-O2 -march=athlon-xp -fomit-frame-pointer -pipe"
CHOST="i686-pc-linux-gnu"
CONFIG_PROTECT="/etc /usr/kde/3.5/env /usr/kde/3.5/share/config /usr/kde/3.5/shutdown /usr/share/config"
CONFIG_PROTECT_MASK="/etc/env.d /etc/env.d/java/ /etc/gconf /etc/php/apache2-php5/ext-active/ /etc/php/cgi-php5/ext-active/ /etc/php/cli-php5/ext-active/ /etc/revdep-rebuild /etc/terminfo /etc/udev/rules.d"
CXXFLAGS="-O2 -march=athlon-xp -fomit-frame-pointer -pipe"
DISTDIR="/usr/portage/distfiles"
FEATURES="ccache distlocks metadata-transfer parallel-fetch sandbox sfperms strict unmerge-orphans userfetch"
GENTOO_MIRRORS="http://gentoo.virginmedia.com http://www.mirrorservice.org/sites/www.ibiblio.org/gentoo http://mirror.qubenet.net/mirror/gentoo http://vlaai.snt.ipv6.utwente.nl/pub/os/linux/gentoo http://gentoo.osuosl.org ftp://mirrors.blueyonder.co.uk/mirrors/gentoo ftp://ftp.mirrorservice.org/sites/www.ibiblio.org/gentoo ftp://ftp.join.uni-muenster.de/pub/linux/distributions/gentoo ftp://mirrors.tds.net/gentoo http://mirrors.tds.net/gentoo http://gentoo.seren.com/gentoo http://gentoo.mirrors.pair.com"
LANG="en_GB.UTF-8"
LC_ALL="en_GB.UTF-8"
LDFLAGS="-Wl,--as-needed"
LINGUAS="en_GB en"
MAKEOPTS="-j2"
PKGDIR="/usr/portage/packages"
PORTAGE_RSYNC_OPTS="--recursive --links --safe-links --perms --times --compress --force --whole-file --delete --delete-after --stats --timeout=180 --exclude=/distfiles --exclude=/local --exclude=/packages --filter=H_**/files/digest-*"
PORTAGE_TMPDIR="/var/tmp"
PORTDIR="/usr/portage"
PORTDIR_OVERLAY="/usr/portage/local/layman/sunrise /usr/portage/local/layman/vmware /usr/local/portage/default"
SYNC="rsync://rsync.gentoo.org/gentoo-portage"
USE=" {removed as unnecessary noise} "
Unset:  CTARGET, EMERGE_DEFAULT_OPTS, INSTALL_MASK, PORTAGE_COMPRESS, PORTAGE_COMPRESS_FLAGS, PORTAGE_RSYNC_EXTRA_OPTS

modules tested (all with same result):-
gspcav1 
vmware-modules 
nvidia-drivers

error received with 2.6.23 and sandbox enabled:-
make[1]: Leaving directory `/usr/src/linux-2.6.23-gentoo'
>>> Source compiled.
--------------------------- ACCESS VIOLATION SUMMARY ---------------------------
LOG FILE = "/var/log/sandbox/sandbox-media-video_-_gspcav1-20070508-8177.log"

open_wr:   /usr/src/linux-2.6.23-gentoo/null.gcda
open_wr:   /usr/src/linux-2.6.23-gentoo/null.gcda
open_wr:   /usr/src/linux-2.6.23-gentoo/null.gcda
open_wr:   /usr/src/linux-2.6.23-gentoo/null.gcda
open_wr:   /usr/src/linux-2.6.23-gentoo/null.gcda
--------------------------------------------------------------------------------

Using FEATURES="-sandbox" does allow them all to compile.

HTH.
Comment 108 Jakub Moc (RETIRED) gentoo-dev 2007-10-14 19:15:35 UTC
*** Bug 195879 has been marked as a duplicate of this bug. ***
Comment 109 Dominique Michel 2007-10-14 19:28:06 UTC
Same thing here, the alsa-driver and nvidia driver compile fine with a 2.6.16-rt29 and a 2.6.19.1-rt15 kernel but they are failing with a 2.6.23-rt1. I don't know for other kernels.

Another issue in my case (*** Bug 195736 ***) is that the alsa-driver did emerge with the sandbox and the 2.6.23-rt1. It fail only with the usersandbox.(In reply to comment #106)

Comment 110 Zac Medico gentoo-dev 2007-10-14 20:01:15 UTC
As said in comment #95, we don't need any more comments about "package X has sandbox violations when built against 2.6.23". The important thing to know is that the patch from comment #88 prevents the sandbox violations that occur when building against the 2.6.23 kernel.
Comment 111 Alon Bar-Lev gentoo-dev 2007-10-14 20:10:38 UTC
zmedico: Are you sure that the linux build system is the one which needed to be fixed? Does it explicitly create null.gcda, or gcc does in specific configuration?
Comment 112 Jakub Moc (RETIRED) gentoo-dev 2007-10-14 20:16:38 UTC
(In reply to comment #111)
> zmedico: Are you sure that the linux build system is the one which needed to be
> fixed? Does it explicitly create null.gcda, or gcc does in specific
> configuration?

Sigh, ZOMG... I'm pretty sure that whatever god-awful hack that kills small kittens and eats your fridge and that will get us rid of this insane dupes flow absolutely needs to be done. So - toolchain, kernel, what's the status here?
Comment 113 Dominique Michel 2007-10-14 20:57:09 UTC
Sorry for the noise.

I applied the patch from comment #88 and emerge did it fine for the alsa-driver with sandbox and usersandbox (2.6.23-rt1).
Comment 114 Daniel Drake (RETIRED) gentoo-dev 2007-10-14 23:18:00 UTC
Thanks for the reports everyone. If you read this, feel free to not add any more, as we have all the information we need and any more just adds noise.

I've been away all weekend. I'll get back onto this case soon.

A change in the kernel build system has made this bug appear on more systems. However it's a legal change and we won't back it out from the kernel.

This bug regards debatable behaviour with gcc (opening a file for read-write which it likely isn't going to write), however that has given rise to a sandbox modification which makes a good deal of sense and would avoid this issue. So, we can fix + enhance sandbox, avoiding this bug, and avoiding having to mess with gcc. Just need a little more time...
Comment 115 Daniel Drake (RETIRED) gentoo-dev 2007-10-16 16:32:37 UTC
*** Bug 195875 has been marked as a duplicate of this bug. ***
Comment 116 Carsten Lohrke (RETIRED) gentoo-dev 2007-10-16 22:54:57 UTC
*** Bug 196105 has been marked as a duplicate of this bug. ***
Comment 117 Jakub Moc (RETIRED) gentoo-dev 2007-10-17 07:55:47 UTC
*** Bug 196138 has been marked as a duplicate of this bug. ***
Comment 118 Daniel Drake (RETIRED) gentoo-dev 2007-10-17 16:05:58 UTC
I just committed sandbox-1.2.18.1-r1. It's in the testing (~arch) tree.  If it doesn't solve the problem for you, please make some noise.

Two or three success reports would be good, but please don't flood us.
Comment 119 Chris Smith 2007-10-17 16:49:29 UTC
(In reply to comment #118)
> I just committed sandbox-1.2.18.1-r1. It's in the testing (~arch) tree.  If it
> doesn't solve the problem for you, please make some noise.
> 
> Two or three success reports would be good, but please don't flood us.
> 

Works here. Thanks!
Comment 120 Frank Krömmelbein 2007-10-17 16:50:18 UTC
Hi,

i just emerged without any Problem the nvidia-drivers with the new sandbox Version.

Thanks Daniel!






Comment 121 boris64 2007-10-17 16:53:19 UTC
Hi, your fix worked fine here.
gcc-4.2.2/kernel-2.6.23.1

Tested ebuilds:
nvidia-drivers / truecrypt

Finally, thx a lot ;)
Comment 122 Craig Andrews gentoo-dev 2007-10-18 03:31:14 UTC
(In reply to comment #118)
> I just committed sandbox-1.2.18.1-r1. It's in the testing (~arch) tree.  If it
> doesn't solve the problem for you, please make some noise.
> 
> Two or three success reports would be good, but please don't flood us.
> 

I can't get the new sandbox to compile on my ~amd64 system.

I do FEATURES="-usersandbox -sandbox" emerge -1 sandbox and the compile fails with:
checking for C compiler default output file name... configure: error: C compiler cannot create executables
Comment 123 Jakub Moc (RETIRED) gentoo-dev 2007-10-18 06:17:58 UTC
(In reply to comment #122)
> (In reply to comment #118)
> checking for C compiler default output file name... configure: error: C
> compiler cannot create executables
 
Please, not here. See Bug 135688 and lots of other duplicates in bugzilla.
Comment 124 Robert A. 2007-10-18 14:52:00 UTC
fix works mostly here (x86 box with sys-devel/gcc-4.1.2, sys-apps/sandbox-1.2.18.1-r1, sys-kernel/vanilla-sources-2.6.23).

tested modules:
tp_smapi, thinkpad, virtualbox-modules, kqemu, vmware-modules, alsa-driver, ipw3945

all modules were installed successfully but the ipw3945 (1.2.0 and 1.2.2):
"open_wr:   /usr/src/linux-2.6.23/.lst"
Comment 125 Sandro Bonazzola 2007-10-18 18:37:24 UTC
(In reply to comment #122)
> (In reply to comment #118)
> I can't get the new sandbox to compile on my ~amd64 system.
> 
> I do FEATURES="-usersandbox -sandbox" emerge -1 sandbox and the compile fails
> with:
> checking for C compiler default output file name... configure: error: C
> compiler cannot create executables

Me too. It seems that CC is set to i686 compiler instead of x86_64.


Comment 126 Craig Andrews gentoo-dev 2007-10-18 19:03:41 UTC
(In reply to comment #125)
> (In reply to comment #122)
> > (In reply to comment #118)
> > I can't get the new sandbox to compile on my ~amd64 system.
> > 
> > I do FEATURES="-usersandbox -sandbox" emerge -1 sandbox and the compile fails
> > with:
> > checking for C compiler default output file name... configure: error: C
> > compiler cannot create executables
> 
> Me too. It seems that CC is set to i686 compiler instead of x86_64.
> 

Take a look at Jakub Moc's reply. Following the instructions from the referenced bug's comments fix the problem for me.
Comment 127 Jakub Moc (RETIRED) gentoo-dev 2007-10-18 19:49:47 UTC
*** Bug 196319 has been marked as a duplicate of this bug. ***
Comment 128 kouyu 2007-10-21 19:02:29 UTC
I have emerged sandbox-1.2.18.1-r1, and re-emerge and re-compile 2.6.23.
And then tp_smapi which can not be emerged before can be emerged now. That's good for me.
But unfortunately, the ipw3945 still can not be emerged due to sandbox violation.
Comment 129 kouyu 2007-10-22 04:05:59 UTC
(In reply to comment #128)
> I have emerged sandbox-1.2.18.1-r1, and re-emerge and re-compile 2.6.23.
> And then tp_smapi which can not be emerged before can be emerged now. That's
> good for me.
> But unfortunately, the ipw3945 still can not be emerged due to sandbox
> violation.
> 
BTW: my arch is amd64 and gcc is 4.2.0
Comment 130 Luca Guglielmetti 2007-10-22 22:38:58 UTC
(In reply to comment #129)
> > I have emerged sandbox-1.2.18.1-r1, and re-emerge and re-compile 2.6.23.
> > And then tp_smapi which can not be emerged before can be emerged now. That's
> > good for me.
I've emerged sandbox-1.2.18.1-r1 too, and now portage install net-wireless/madwifi-ng-0.9.3.3 correctly.
Thanks to the devs for the bugfix ;)
Comment 131 Jakub Moc (RETIRED) gentoo-dev 2007-10-24 09:27:37 UTC
*** Bug 196901 has been marked as a duplicate of this bug. ***
Comment 132 Daniel Drake (RETIRED) gentoo-dev 2007-10-24 14:44:07 UTC
Thanks for the feedback. The ipw3945 sandbox violations are unrelated and specific to ipw3945 -- there is probably a relevant bug open about that.

I've asked arch teams to stable the new sandbox version in bug #196931, so I'll mark this as fixed. Sorry that this bug took so long to solve.
Comment 133 Robert A. 2007-10-24 19:20:57 UTC
(In reply to comment #132)
> Thanks for the feedback. The ipw3945 sandbox violations are unrelated and
> specific to ipw3945 -- there is probably a relevant bug open about that.

searching through bugzilla i find three bugs regarding the ipw3945 issue. all (195137, 195586, 196319) are marked as duplicates of this bug.
Comment 134 Daniel Drake (RETIRED) gentoo-dev 2007-10-24 20:12:09 UTC
OK, thanks for looking, I've reopened bug #195137 for you.
Comment 135 Jakub Moc (RETIRED) gentoo-dev 2007-10-26 08:15:13 UTC
*** Bug 197074 has been marked as a duplicate of this bug. ***
Comment 136 Henning Rogge 2007-11-02 14:34:01 UTC
I had the same problem. (~amd64 system).
Sandbox violations for nvidia-drivers, madwifi-ng wlan-driver and alsa-drivers when I updated to gentoo-sources 2.6.23.

After a downgrade to gentoo-sources-2.6.22-r8 all three drivers compiled without a problem.

When I updated to sandbox-1.2.18.1-r2 and upgraded to gentoo-sources-2.6.23 everything compiled fine.
Comment 137 Jakub Moc (RETIRED) gentoo-dev 2007-11-19 07:18:27 UTC
*** Bug 199636 has been marked as a duplicate of this bug. ***
Comment 138 Jan Kundrát (RETIRED) gentoo-dev 2007-12-05 16:33:03 UTC
*** Bug 201373 has been marked as a duplicate of this bug. ***
Comment 139 Jakub Moc (RETIRED) gentoo-dev 2008-01-07 19:34:11 UTC
*** Bug 204733 has been marked as a duplicate of this bug. ***
Comment 140 Jakub Moc (RETIRED) gentoo-dev 2008-01-29 09:26:11 UTC
*** Bug 208006 has been marked as a duplicate of this bug. ***
Comment 141 Carsten Lohrke (RETIRED) gentoo-dev 2008-06-21 23:11:50 UTC
*** Bug 228743 has been marked as a duplicate of this bug. ***