Summary: | app-editors/emacs-24.3-r2 USE=X - sandbox violation in /dev/dri/card0 by ./src/emacs --version | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | Erik Zeek <zeekec> |
Component: | Current packages | Assignee: | Gentoo X packagers <x11> |
Status: | RESOLVED DUPLICATE | ||
Severity: | normal | CC: | dschridde+gentoobugs, emacs, xarthisius |
Priority: | Normal | ||
Version: | unspecified | ||
Hardware: | All | ||
OS: | Linux | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- | |
Attachments: |
app-editors:emacs-24.3-r2:20130830-031920.log.gz
strace emacs --version 2>emacs.strace strace emacs --version 2>emacs.strace |
Description
Erik Zeek
2013-08-30 03:59:38 UTC
I cannot reproduce this. Something strange is going on here: F: open_wr S: deny P: /dev/dri/card0 A: /dev/dri/card0 R: /dev/dri/card0 C: ./src/emacs --version With the --version option, Emacs outputs the version and exits immediately. This is before display initialisation. Can you post the stderr output of "strace emacs --version"? Created attachment 357474 [details]
strace emacs --version 2>emacs.strace
(In reply to Erik Zeek from comment #2) > Created attachment 357474 [details] > strace emacs --version 2>emacs.strace Looks like some library does nasty things when initialising ... > open("/usr/lib64/libOpenCL.so.1", O_RDONLY|O_CLOEXEC) = 3 Can you build the depending libs (at least mesa and imagemagick, maybe more) with USE=-opencl and then try if the problem still occurs? Created attachment 357484 [details]
strace emacs --version 2>emacs.strace
The strace after building with -opencl. This seems to have fixed it.
(In reply to Erik Zeek from comment #2) > Created attachment 357474 [details] > strace emacs --version 2>emacs.strace Looks like some library does nasty things when initialising ... > open("/usr/lib64/libOpenCL.so.1", O_RDONLY|O_CLOEXEC) = 3 Can you build the depending libs (at least mesa and imagemagick, maybe more) with USE=-opencl and then try if the problem still occurs? Sorry for the duplicate comment. X11 team, any idea what is happening here? "emacs --version" just does option parsing, outputs the version with printf, and then exits immediately. It appears that some library attempts to execute OpenCL code during build. This is not a problem when the OpenCL code is run on the CPU but it causes a sandbox violation when it is attempted run on the GPU. Unfortunately I don't know of a generic way to force OpenCL to use the CPU. A workaround might be to set the OCL_ICD_VENDORS environment variable to a bogus directory so that libOpenCL won't find any icd, which will prevent OpenCL code from being run at all. (In reply to Chí-Thanh Christopher Nguyễn from comment #8) > A workaround might be to set the OCL_ICD_VENDORS environment variable to a > bogus directory so that libOpenCL won't find any icd, which will prevent > OpenCL code from being run at all. Adding such workarounds to random ebuilds like emacs doesn't look right to me. Emacs doesn't deal with OpenCL directly, only via some libraries (whose functions aren't even called when doing emacs --version). Reassigning to x11. See-Also: bug #472688, bug #485422, bug #490457 I suspect this is a duplicate of bug 472766? I'm not 100% sure. Does the emacs binary somehow link to ImageMagick, or is this entirely separate OpenCL issue? Please mark this as a duplicate of bug 472766, if it's indeed about the same thing, and it's indeed ImageMagick that should own any future sandbox.d file (In reply to Samuli Suominen from comment #11) > I suspect this is a duplicate of bug 472766? I'm not 100% sure. > Does the emacs binary somehow link to ImageMagick, or is this entirely > separate OpenCL issue? Emacs with USE=imagemagick links to ImageMagick indeed. (In reply to Erik Zeek from comment #4) > Created attachment 357484 [details] > strace emacs --version 2>emacs.strace > > The strace after building with -opencl. This seems to have fixed it. Not sure if "building with -opencl" refers to imagemagick only. (But my question in comment #3 was equally unprecise.) @Erik: Can you build media-gfx/imagemagick with and without USE=opencl (but no changes to other packages), and try to reproduce the problem in either case? =media-gfx/imagemagick-6.8.8.10[opencl] installs a /etc/sandbox.d file with content of SANDBOX_PREDICT="/dev/dri/card" now that should workaround the problem if that solves the emacs bug too, please dupe to bug 472766 (In reply to Samuli Suominen from comment #13) > =media-gfx/imagemagick-6.8.8.10[opencl] installs a /etc/sandbox.d file with > content of SANDBOX_PREDICT="/dev/dri/card" now that should workaround the > problem > if that solves the emacs bug too, please dupe to bug 472766 I can no longer replicate this bug. I tried removing the sandbox file and emerging emacs, and I got no sandbox violations. I don't know what might have changed to fix it. I'll mark it as WORKSFORME and not a dupe. *** This bug has been marked as a duplicate of bug 472766 *** |