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
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.
4) add a call to `addpredict`
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...
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".
(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
(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.
uhh, no it doesnt ... otherwise addpredict would be the samething as addwrite addpredict() { export SANDBOX_PREDICT="$SANDBOX_PREDICT:$1" }
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?
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 ...
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.
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.
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
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.
agreed, ignore my previous comment :)
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.
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 :)
Committed to svn. Will see if I get time to add it to ~ sandbox.
*** Bug 159314 has been marked as a duplicate of this bug. ***
The last comment is 6 month ago. Is anyone working on this?
*** Bug 166093 has been marked as a duplicate of this bug. ***
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]
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.
*** Bug 170211 has been marked as a duplicate of this bug. ***
*** Bug 170945 has been marked as a duplicate of this bug. ***
*** Bug 171574 has been marked as a duplicate of this bug. ***
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? :/)
Some kind of workaround for this can be using ebuild /usr/portage{package}.ebuild merge (somtimes must be run twice to get the effect).
*** Bug 171895 has been marked as a duplicate of this bug. ***
*** Bug 174089 has been marked as a duplicate of this bug. ***
*** Bug 176294 has been marked as a duplicate of this bug. ***
*** Bug 176791 has been marked as a duplicate of this bug. ***
*** Bug 177886 has been marked as a duplicate of this bug. ***
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?
(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
(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?
*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
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...
*** Bug 185946 has been marked as a duplicate of this bug. ***
*** Bug 186422 has been marked as a duplicate of this bug. ***
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
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.
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.
*** Bug 187749 has been marked as a duplicate of this bug. ***
*** Bug 189332 has been marked as a duplicate of this bug. ***
*** Bug 189333 has been marked as a duplicate of this bug. ***
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
*** Bug 190529 has been marked as a duplicate of this bug. ***
I'm adding app-emulation/kqemu to the list. I'll read on/test stuff later.
*** Bug 191403 has been marked as a duplicate of this bug. ***
*** Bug 191564 has been marked as a duplicate of this bug. ***
*** Bug 191731 has been marked as a duplicate of this bug. ***
*** Bug 192698 has been marked as a duplicate of this bug. ***
*** Bug 193827 has been marked as a duplicate of this bug. ***
*** Bug 193912 has been marked as a duplicate of this bug. ***
(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
*** Bug 195042 has been marked as a duplicate of this bug. ***
*** Bug 195137 has been marked as a duplicate of this bug. ***
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...
*** Bug 195299 has been marked as a duplicate of this bug. ***
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.
this should block bug 195298
(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
> > 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.
(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.
*** Bug 195393 has been marked as a duplicate of this bug. ***
*** Bug 195392 has been marked as a duplicate of this bug. ***
*** Bug 195381 has been marked as a duplicate of this bug. ***
currently (w/gentoo-sources-2.6.23 in case this is relavent) prevents vlc emerge as well as nvidia-drivers and alsa-drivers
(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 --------------------------------------------------------------------------------
(In reply to comment #69) > open_wr: /var/cache/samba/gencache.tdb Unrelated, Bug 121573.
*** Bug 195413 has been marked as a duplicate of this bug. ***
*** Bug 195420 has been marked as a duplicate of this bug. ***
(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.
(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.
*** Bug 195434 has been marked as a duplicate of this bug. ***
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...
(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.
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.
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?
(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)
<<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 *
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.
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 --------------------------------------------------------------------------------
*** Bug 195500 has been marked as a duplicate of this bug. ***
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 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
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
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.
(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.
I can build external modules in 2.6.22, but no one in 2.6.23
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.
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.
(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.
(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
(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.
*** Bug 195583 has been marked as a duplicate of this bug. ***
*** Bug 195586 has been marked as a duplicate of this bug. ***
*** Bug 195581 has been marked as a duplicate of this bug. ***
*** Bug 195598 has been marked as a duplicate of this bug. ***
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?
> 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
To be precise, it's: FEATURES="-sandbox -usersandbox" emerge ...
Use the *forums* to ask such questions. See http://forums.gentoo.org/viewtopic-t-597887.html
*** Bug 195650 has been marked as a duplicate of this bug. ***
*** Bug 195657 has been marked as a duplicate of this bug. ***
*** Bug 195736 has been marked as a duplicate of this bug. ***
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.
*** Bug 195879 has been marked as a duplicate of this bug. ***
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)
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.
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?
(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?
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).
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...
*** Bug 195875 has been marked as a duplicate of this bug. ***
*** Bug 196105 has been marked as a duplicate of this bug. ***
*** Bug 196138 has been marked as a duplicate of this bug. ***
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.
(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!
Hi, i just emerged without any Problem the nvidia-drivers with the new sandbox Version. Thanks Daniel!
Hi, your fix worked fine here. gcc-4.2.2/kernel-2.6.23.1 Tested ebuilds: nvidia-drivers / truecrypt Finally, thx a lot ;)
(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
(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.
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"
(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.
(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.
*** Bug 196319 has been marked as a duplicate of this bug. ***
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.
(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
(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 ;)
*** Bug 196901 has been marked as a duplicate of this bug. ***
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.
(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.
OK, thanks for looking, I've reopened bug #195137 for you.
*** Bug 197074 has been marked as a duplicate of this bug. ***
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.
*** Bug 199636 has been marked as a duplicate of this bug. ***
*** Bug 201373 has been marked as a duplicate of this bug. ***
*** Bug 204733 has been marked as a duplicate of this bug. ***
*** Bug 208006 has been marked as a duplicate of this bug. ***
*** Bug 228743 has been marked as a duplicate of this bug. ***
