| View previous topic :: View next topic |
| Author |
Message |
VValdo
Guru
Joined: 08 Jan 2005
Posts: 395
|
 Posted: Fri Mar 24, 2006 7:46 pm Post subject: epiphany 2.16.2 sandbox violation? |
 |
|
Anyone else seeing this bug when compiling epiphany 2.14?
| Code: | --------------------------- ACCESS VIOLATION SUMMARY ---------------------------
LOG FILE = "/var/log/sandbox/sandbox-www-client_-_epiphany-2.14.0-6736.log"
open_wr: /usr/lib64/mozilla-firefox/components/xpti.dat.tmp
open_wr: /usr/lib64/mozilla-firefox/components/xpti.dat.tmp
open_wr: /usr/lib64/mozilla-firefox/components/compreg.dat.tmp
open_wr: /usr/lib64/mozilla-firefox/components/compreg.dat.tmp
open_wr: /usr/lib64/mozilla-firefox/components/xpti.dat.tmp
open_wr: /usr/lib64/mozilla-firefox/components/xpti.dat.tmp
open_wr: /usr/lib64/mozilla-firefox/components/compreg.dat.tmp
open_wr: /usr/lib64/mozilla-firefox/components/compreg.dat.tmp
open_wr: /usr/lib64/mozilla-firefox/components/xpti.dat.tmp
open_wr: /usr/lib64/mozilla-firefox/components/xpti.dat.tmp
open_wr: /usr/lib64/mozilla-firefox/components/compreg.dat.tmp
open_wr: /usr/lib64/mozilla-firefox/components/compreg.dat.tmp
open_wr: /usr/lib64/mozilla-firefox/components/xpti.dat.tmp
open_wr: /usr/lib64/mozilla-firefox/components/xpti.dat.tmp
open_wr: /usr/lib64/mozilla-firefox/components/compreg.dat.tmp
open_wr: /usr/lib64/mozilla-firefox/components/compreg.dat.tmp
open_wr: /usr/lib64/mozilla-firefox/components/xpti.dat.tmp
open_wr: /usr/lib64/mozilla-firefox/components/xpti.dat.tmp
open_wr: /usr/lib64/mozilla-firefox/components/compreg.dat.tmp
open_wr: /usr/lib64/mozilla-firefox/components/compreg.dat.tmp
open_wr: /usr/lib64/mozilla-firefox/components/xpti.dat.tmp
open_wr: /usr/lib64/mozilla-firefox/components/xpti.dat.tmp
open_wr: /usr/lib64/mozilla-firefox/components/compreg.dat.tmp
open_wr: /usr/lib64/mozilla-firefox/components/compreg.dat.tmp
-------------------------------------------------------------------------------- |
(that's the amd64 version.)
See: http://bugs.gentoo.org/show_bug.cgi?id=126253 -- no one has yet posted a solution.
More notes on this at breakmygentoo.com:
https://bugs.breakmygentoo.net/view.php?id=159
No solution was posted (yet) for the 2.14.0 ebuild there either.
W
Last edited by VValdo on Mon Nov 20, 2006 8:39 pm; edited 1 time in total |
|
| Back to top |
|
 |
OrangeToque
n00b
Joined: 03 Apr 2006
Posts: 57
Location: Edmonton, Alberta, Canada
|
| Posted: Mon Apr 03, 2006 3:31 pm Post subject: |
|
|
I had the exact same problem, It was driving me crazy!
I have, however found two solutions to the problem ::
1. Add the following line to /etc/portage/package.use
| Code: | | www-client/epiphany -firefox |
* This will compile epiphany against Mozilla, not firefox. This solution requires the compilation of Mozilla, and I was not happy with this solution!!
2. Emerge epiphany with the -sandbox option
| Code: | | FEATURES="-sandbox" emerge epiphany |
* This solution allowed epiphany to be compiled and run against firefox, without compiling Mozilla!
I would try the second solution first, and if that doesn't work, then I would resort to the first solution.
Good luck!
Last edited by OrangeToque on Fri Apr 07, 2006 4:00 pm; edited 1 time in total |
|
| Back to top |
|
|
Principal Skinner
n00b
Joined: 27 Nov 2002
Posts: 50
Location: Greenbelt, Maryland, USA
|
| Posted: Tue Apr 04, 2006 6:45 am Post subject: Second Solution |
|
|
| OrangeToque wrote: |
I would try the second solution first, and if that doesn't work, then I would resort to the second solution. |
So... you're in favor of the second solution if the second solution doesn't work?  |
|
| Back to top |
|
|
OrangeToque
n00b
Joined: 03 Apr 2006
Posts: 57
Location: Edmonton, Alberta, Canada
|
| Posted: Fri Apr 07, 2006 4:01 pm Post subject: Re: Second Solution |
|
|
| Principal Skinner wrote: | | OrangeToque wrote: |
I would try the second solution first, and if that doesn't work, then I would resort to the second solution. |
So... you're in favor of the second solution if the second solution doesn't work? |
Oooops! |
|
| Back to top |
|
|
caffeine_junkie
Tux's lil' helper
Joined: 08 Jan 2004
Posts: 133
Location: Vienna, Austria
|
| Posted: Thu Apr 20, 2006 9:36 am Post subject: |
|
|
the 2nd workaround did it for me, but i still got epiphany working with the gecko-1.8 backend.
is there a way to change this after compilation?
do i have both backends now?
or do i have to recompile it with -mozilla use flag? |
|
| Back to top |
|
|
VValdo
Guru
Joined: 08 Jan 2005
Posts: 395
|
| Posted: Mon Apr 24, 2006 6:31 pm Post subject: |
|
|
Dunno. Wierd that after like 3 weeks this still isn't fixed. I'm trying the "-sandbox" method right now...
Update: It worked... go figure.
W |
|
| Back to top |
|
|
reup
Guru
Joined: 13 May 2005
Posts: 374
Location: Nederland
|
| Posted: Wed Apr 26, 2006 12:37 pm Post subject: what is sandbox ? |
|
|
having the same problem, I was currious about what the heck is sandbox. it is interresting as it shows that emerge epiphany is trying to write to some place where it should not.
from : http://bugday.gentoo.org/sandbox.html
| Quote: |
A sandbox violation is any attempt by an ebuild during an emerge to write outside the portage predefined staging area or protected environment known as the sandbox. |
reup |
|
| Back to top |
|
|
VValdo
Guru
Joined: 08 Jan 2005
Posts: 395
|
| Posted: Tue May 02, 2006 3:04 am Post subject: |
|
|
This bug appears to still exist with epiphany 2.14.1.
Bug here.
W |
|
| Back to top |
|
|
VValdo
Guru
Joined: 08 Jan 2005
Posts: 395
|
| Posted: Thu May 11, 2006 4:03 am Post subject: |
|
|
...and 2.14.1-r1.
W |
|
| Back to top |
|
|
MAST
n00b
Joined: 31 Dec 2005
Posts: 74
Location: Spain
|
| Posted: Mon May 22, 2006 8:46 am Post subject: |
|
|
same problem 2.14.1-r1
_________________
César ----------  ---------------- |
|
| Back to top |
|
|
urcindalo
Guru
Joined: 08 Feb 2005
Posts: 514
Location: Almeria, Spain
|
| Posted: Wed Jul 19, 2006 11:49 am Post subject: |
|
|
| Also with epiphany-2.14.2.1 on AMD64 |
|
| Back to top |
|
|
hamaker
n00b
Joined: 09 Sep 2004
Posts: 73
Location: Netherlands
|
| Posted: Thu Jul 20, 2006 6:58 pm Post subject: |
|
|
| ...and 2.14.2-r1 on AMD64... |
|
| Back to top |
|
|
Mad Alex
n00b
Joined: 22 Feb 2005
Posts: 5
Location: York, UK
|
| Posted: Sat Jul 22, 2006 2:07 pm Post subject: Found the cause of the sandbox violations and a hackish fix |
|
|
After some happy hacking I have identified the cause of the access violations, at least for amd64. The access violations are occurring during the configure stage only (for me at least) and from just a few lines related to the gecko checks in configure.ac.
See the bug for the gory details.
The good old method of "comment out the offending code and pray to the gods of computing that nothing breaks as a consequence" allowed the emerge to complete successfully (and the resulting build is working). I have attached a patch to the bug to apply those changes.
To use my patch you will need to create a copy of the ebuild in a portage overlay and hack it to apply my patch; simply duplicate the line with applies the 1.9.2-broken-firefox patch and adapt it in the obvious way for the additional patch (which should also be placed in the files sub-directory). Of course on your setup it might not completely fix the problem and / or might break other things, especially if not on amd64. But hey, it works for me!  |
|
| Back to top |
|
|
Gergan Penkov
Veteran
Joined: 17 Jul 2004
Posts: 1464
Location: das kleinste Kuhdorf Deutschlands :)
|
| Posted: Sat Jul 22, 2006 2:29 pm Post subject: |
|
|
only to comment on your bug comment:
the macro is defined in epiphany, but this does not make it less firefox-upstream bug as the code goes like this (note this is from epiphany-cvs):
| Code: | # GECKO_CHECK_CONTRACTID(CONTRACTID, [ACTION-IF-FOUND], [ACTION-IF-NOT-FOUND])
#
# Checks wheter CONTRACTID is a registered contract ID
AC_DEFUN([GECKO_CHECK_CONTRACTID],
[AC_REQUIRE([GECKO_INIT])dnl
AS_VAR_PUSHDEF([gecko_cv_have_CID],[gecko_cv_have_$1])
AC_CACHE_CHECK([for the $1 XPCOM component],
gecko_cv_have_CID,
[
AS_VAR_SET(gecko_cv_have_CID,[no])
GECKO_RUN_IFELSE([],
[GECKO_XPCOM_PROGRAM([[
#include <nsIComponentRegistrar.h>
]],[[
status = 99;
nsCOMPtr<nsIComponentRegistrar> registrar;
rv = NS_GetComponentRegistrar (getter_AddRefs (registrar));
if (NS_FAILED (rv)) break;
status = 98;
PRBool isRegistered = PR_FALSE;
rv = registrar->IsContractIDRegistered ("$1", &isRegistered);
if (NS_FAILED (rv)) break;
status = isRegistered ? EXIT_SUCCESS : 97;
]])
],
[AS_VAR_SET(gecko_cv_have_CID,[yes])],
[AS_VAR_SET(gecko_cv_have_CID,[no])],
[AS_VAR_SET(gecko_cv_have_CID,[maybe])])
])
if test AS_VAR_GET(gecko_cv_have_CID) = "yes"; then
ifelse([$2],,[:],[$2])
else
ifelse([$3],,[AC_MSG_ERROR([dnl
Contract ID "$1" is not registered, but $PACKAGE_NAME depends on it.])],
[$3])
fi
AS_VAR_POPDEF([gecko_cv_have_CID])
]) # GECKO_CHECK_CONTRACTID
|
the problem is that either NS_GetComponentRegistrar or registrar->IsContractIDRegistered causes a write, which does not make any sense.
_________________
"I knew when an angel whispered into my ear,
You gotta get him away, yeah
Hey little bitch!
Be glad you finally walked away or you may have not lived another day."
Godsmack |
|
| Back to top |
|
|
nizar
Apprentice
Joined: 19 Dec 2003
Posts: 256
Location: localhost
|
| Posted: Tue Aug 01, 2006 7:26 pm Post subject: |
|
|
The same here.
I'm getting the access violation in almost every ebuild!
sandbox-media-video_-_totem-1.4.2-24074.log
| Code: |
open_wr: /admin/.gconf/.testing.writeability
unlink: /admin/.gconf/.testing.writeability
open_wr: /admin/.gconfd/saved_state
open_wr: /admin/.gconfd/saved_state
open_wr: /admin/.gconfd/saved_state
open_wr: /admin/.gconfd/saved_state
open_wr: /admin/.gconfd/saved_state
open_wr: /admin/.gconfd/saved_state
open_wr: /admin/.gconfd/saved_state
open_wr: /admin/.gconfd/saved_state
open_wr: /admin/.gconfd/saved_state
open_wr: /admin/.gconfd/saved_state.tmp
|
sandbox-gnome-extra_-_gnome-media-2.14.2-18378.log
| Code: |
open_wr: /admin/.gconf/.testing.writeability
unlink: /admin/.gconf/.testing.writeability
open_wr: /admin/.gconfd/saved_state
open_wr: /admin/.gconfd/saved_state
open_wr: /admin/.gconfd/saved_state
open_wr: /admin/.gconfd/saved_state
open_wr: /admin/.gconfd/saved_state
open_wr: /admin/.gconfd/saved_state
open_wr: /admin/.gconfd/saved_state
open_wr: /admin/.gconfd/saved_state
open_wr: /admin/.gconfd/saved_state
open_wr: /admin/.gconfd/saved_state.tmp
|
(/admin is root's homedir)
I had no choice, know I'm compiling with FEATURE="-sandbox". |
|
| Back to top |
|
|
leahcim
n00b
Joined: 17 Mar 2003
Posts: 29
|
| Posted: Fri Aug 18, 2006 2:22 pm Post subject: |
|
|
| Gergan Penkov wrote: | only to comment on your bug comment:
the problem is that either NS_GetComponentRegistrar or registrar->IsContractIDRegistered causes a write, which does not make any sense. |
Not exactly, the whole program that compiles and is run from that macro has more code, it could be a line in GECKO_XPCOM_PROGRAM [m4/gecko.m4]
The configure.log lines for example :-
| Code: | configure:23558: checking whether we can compile and run XPCOM programs
configure:23667: x86_64-pc-linux-gnu-g++ -o conftest -march=athlon64 -pipe -O3 -funit-at-a-time -fforce-addr -fpeel-loops -funswitch-loops -fno-rtti -fshort-wchar -I/usr/lib64/mozilla-firefox/include -I/usr/lib64/mozilla-firefox/include -I/usr/lib64/mozilla-firefox/include/xpcom -I/usr/lib64/mozilla-firefox/include/string -I/usr/include/nspr -I/usr/lib64/mozilla-firefox/include/dom -I/usr/lib64/mozilla-firefox/include/necko -I/usr/lib64/mozilla-firefox/include/pref -Wl,--rpath=/usr/lib64/mozilla-firefox conftest.cc -Wl,-R/usr/lib64/mozilla-firefox -Wl,-R/usr/lib64/nspr -L/usr/lib64/mozilla-firefox -L/usr/lib64/nspr -lxpcom -lplds4 -lplc4 -lnspr4 -lpthread -ldl >&5
configure:23670: $? = 0
configure:23672: ./conftest
^[[31;01mACCESS DENIED^[[0m open_wr: /usr/lib64/mozilla-firefox/components/xpti.dat.tmp
^[[31;01mACCESS DENIED^[[0m open_wr: /usr/lib64/mozilla-firefox/components/xpti.dat.tmp
^[[31;01mACCESS DENIED^[[0m open_wr: /usr/lib64/mozilla-firefox/components/compreg.dat.tmp
^[[31;01mACCESS DENIED^[[0m open_wr: /usr/lib64/mozilla-firefox/components/compreg.dat.tmp
configure:23675: $? = 0
configure:23704: result: yes
|
Because all the gecko programs that are run in the configure.log, print these ACCESS DENIED lines that suggests to me that it's simply running an XPCOM program that will trigger this, and therefore it's part of the code in the macro rather than the code in the individual test that's the issue. Perhaps InitXpcom2?
Pulling out the conftest.cc code for the case above, compiling and and running it appears to do [at least] 2 things
(a) creates a xpti.dat and compreg.dat in /usr/lib64/mozilla-firefox/components [/usr/lib64/mozilla-firefox is the $_GECKO_HOME in the code]
(b) subsequently allows epiphany to then be compiled / merged via emerge without the previous complaints about sandbox errors.
Perhaps that points to this being some "you need to run $something as root after installing firefox" issue to get it to create these files outside of emerge's sandbox?
That would explain why some [in the bug report] don't have / can't recreate the problem. [Certainly on amd64, I don't run firefox at all, as any user because I use firefox-bin + flash plugin]
These files appear all over the place in /home/user/.mozilla/firefox and thunderbird directories, so they are evidently created in user dirs when run as a user rather than in the main /usr/lib64/,... dirs
edit: Doesn't debian have a specific thing to create these xpti.dat and compreg.dat files as part of install? Perhaps, as part of the install process, compiling + running an XPCOM program [i.e like the one in the configure test that fails inside the sandbox] could be run to create the files outside the sandbox and thus the bug / fix might be better placed against mozilla-firefox? |
|
| Back to top |
|
|
mariourk
l33t
Joined: 11 Jul 2003
Posts: 804
Location: Urk, Netherlands
|
| Posted: Sun Oct 15, 2006 5:32 pm Post subject: |
|
|
I get this error with epiphany-2.16.1.
Also AMD64.
_________________
If there is one thing to learn from history, it's that we usualy don't learn anything from it, at all. |
|
| Back to top |
|
|
Melaskia
n00b
Joined: 23 May 2004
Posts: 33
|
| Posted: Thu Oct 26, 2006 1:59 pm Post subject: |
|
|
| same here quite frustrating |
|
| Back to top |
|
|
VValdo
Guru
Joined: 08 Jan 2005
Posts: 395
|
| Posted: Mon Nov 20, 2006 8:37 pm Post subject: |
|
|
2.16.2 too.
W |
|
| Back to top |
|
|
VValdo
Guru
Joined: 08 Jan 2005
Posts: 395
|
| Posted: Thu Feb 08, 2007 8:18 pm Post subject: |
|
|
2.16.3.
Sigh.
W |
|
| Back to top |
|
|
VValdo
Guru
Joined: 08 Jan 2005
Posts: 395
|
| Posted: Tue Mar 27, 2007 9:26 pm Post subject: |
|
|
And the sandbox violation, still here at 2.18.0.
W |
|
| Back to top |
|
|
VValdo
Guru
Joined: 08 Jan 2005
Posts: 395
|
| Posted: Sat Jun 30, 2007 5:44 pm Post subject: |
|
|
2.18.2 also has this problem.
W |
|
| Back to top |
|
|
wolfden
Tux's lil' helper
Joined: 13 Oct 2004
Posts: 102
Location: Midwest
|
| Posted: Mon Jul 02, 2007 7:46 am Post subject: |
|
|
It sure is  |
|
| Back to top |
|
|
VValdo
Guru
Joined: 08 Jan 2005
Posts: 395
|
| Posted: Sat Aug 11, 2007 11:02 pm Post subject: |
|
|
Hey guys--
I have a fix, complements of bug bug 126253 linked above:
| Quote: | As for your problem, I think maybe your multilib is broken. It looks from the
output like you have /usr/lib64 as a symlink to /usr/lib. This is backwards,
and has been for many releases. /usr/lib should be a symlink to /usr/lib64
(and /lib should be a symlink to /lib64). |
Daniel Gryniewicz figured it out!
To fix, I "mv"ed /lib64 to /waslib64 then "mv"ed /lib to /lib64 then "ln -s /lib64 /lib" (ie, symlink /lib -> lib64) then "rm"ed /waslib64. I then did the same thing for /usr/lib and /usr/lib64. (there's a more efficient way to do this, ie, just deleting the /lib64 link to begin with, but I was being cautious)
Warning: when you're fixing this... be VERY careful. You may end up in a situation where you've just killed your /lib64 or /usr/lib64 directory. When that happens, you lose useful commands like "ls" and "mv".
The solution if/when this happens: use busybox's version instead, like so:
| Code: | | ./bin/busybox.static mv lib lib64 |
I would check to make sure that busybox works, because you don't wanna get caught with your whole library directory gone for too long.
Once I had /lib linking to /lib64 and /usr/lib linking to /usr/lib64 I was able to emerge epiphany w/o sandbox violations.
W |
|
| Back to top |
|
|
rlittle
Apprentice
Joined: 17 Dec 2003
Posts: 200
|
| Posted: Sun Aug 12, 2007 2:55 pm Post subject: |
|
|
VValdo, you and Daniel Gryniewicz are my heros! You represent one of the pillars of Bugzilla.
Many thanks. I will no longer have to futz around with epiphany workarounds! Thank you!
Epiphany compiled absurdly fast on my system now also. 
_________________
I need a better signature... |
|
| Back to top |
|
|
|
Desktop Environments
