Created attachment 367364 [details] emerge --info emacs I did a deep world update recently ("emerge -avuDN --with-bdeps=y world"), and I found that emacs-24.3-r2 is not re-emerging correctly (it worked before). The only major dependency that was updated was glibc (2.16 -> 2.17). Note that this is *not* a segfault, so it is probably not the same as bug 494316 or 456970 (and there is no core file). In fact temacs produces no output before dying.
Created attachment 367366 [details] build.log
The process probably got killed because you ran out of memory.
Doesn't seem likely. I have only 1.5GB/4GB used when this command is run (plus 4GB swap space). Besides which, this is quite reproducible now, and didn't happen before, so to me it seems more likely that this is due to either: - a change in the emacs ebuild (though it would have to have been one without a revbump), - an issue related to some dependency, or - some change in the hardened kernel over the last few months. Unfortunately I don't have much to go on right now. Kernel log shows only one message during the emerge. Emacs' conftest requested RLIMIT_NOFILE to be raised to 1000000 and was denied (according to grsec), but there's no sign that there was a problem with the actual limit (1024). Most hardened problems I know of would result in an actual segfault and/or another security message of some kind. (P.S.: I should clarify that glibc was the only significant update that happened during this emerge. I can't tell you for sure when the last time I successfully emerged Emacs is, except that it was in the last 6 months.)
Can you emerge emacs-24.2-r1? This ebuild has had no non-trivial changes since 10 months.
Hmm. It seems that I can emerge emacs-24.2-r1.
The only nontrivial changes in emacs-24.3-r2.ebuild during the last 6 months were a fix for bug 473364 (build failure on FreeBSD) and for bug 456970 (PaX/xattr). I believe that they are unlikely to cause any breakage, but you can undo both changes by selecting a previous patchset in SRC_URI: SRC_URI="mirror://gnu/emacs/${P}.tar.xz - http://dev.gentoo.org/~ulm/emacs/${P}-patches-4.tar.xz" + http://dev.gentoo.org/~ulm/emacs/${P}-patches-2.tar.xz"
Hmm. patches-2 and patches-3 work fine. It seems to be the paxctl change causing the problem.
Can you attach the kernel config? Especially, what are the values of XATTR_PAX_FLAGS and PT_PAX_FLAGS?
Both PAX_FLAGS types are on, because this system has been around a little while and I haven't transitioned entirely to XATTR yet. In fact, thinking about that, I've figured out the problem: > sudo paxctl -v /var/tmp/portage/app-editors/emacs-24.3-r2/work/emacs-24.3/src/temacs PaX control v0.7 Copyright 2004,2005,2006,2007,2009,2010,2011,2012 PaX Team <pageexec@freemail.hu> - PaX flags: -------x-e-r [/var/tmp/portage/app-editors/emacs-24.3-r2/work/emacs-24.3/src/temacs] RANDEXEC is disabled EMUTRAMP is disabled RANDMMAP is disabled > sudo getfattr -n user.pax.flags /var/tmp/portage/app-editors/emacs-24.3-r2/work/emacs-24.3/src/temacs getfattr: Removing leading '/' from absolute path names # file: var/tmp/portage/app-editors/emacs-24.3-r2/work/emacs-24.3/src/temacs user.pax.flags="r" There's no way that would work; the two types have to match exactly, or else the process is immediately killed. I would suggest that you could change the patch in one of the following ways: 1) Set user.pax.flags to "xer" instead of just "r". That's still "wrong" in the sense that it could differ from the PT_PAX markings, but it's likely to be right more often in the near future. 2) If you're going to mark temacs for both PT_PAX and the XATTR_PAX, use paxctl-ng to copy flags over (probably the best fix?). 3) Check the output of "paxctl -v" to set user.pax.flags (i.e. the same as what "paxctl-ng -F" does, but more manually). You probably know better than I do what upstream is doing, if that plays into this at all.
Alternatively, if I missed the memo and Gentoo isn't supporting kernels with both options enabled anymore, I guess it's my problem and I need to finish switching over to XATTR.
Thanks for the analysis. This looks similar to the issue from bug 447150, where the conclusion was that only the "e" flag should be set in addition. Can you try if this is enough for fixing the problem (line 474 of src/Makefile.in): - $(SETFATTR) -n user.pax.flags -v r temacs$(EXEEXT) + $(SETFATTR) -n user.pax.flags -v er temacs$(EXEEXT) I'm surprised why this would be needed though, because "e" should be the default. Does setfattr -n user.pax.flags -v r silently enable EMUTRAMP? (In reply to Sean Santos from comment #10) > Alternatively, if I missed the memo and Gentoo isn't supporting kernels with > both options enabled anymore, I guess it's my problem and I need to finish > switching over to XATTR. I cannot answer this. CCing hardened-kernel team.
Ah, well, I guess that the "x" is ignored because RANDEXEC isn't used anymore. But the "e" is necessary to make sure that the other markings are the same. I don't think it matters what the default behavior is; a flag that's not specified won't match a flag that's specified as either on or off, so the process is killed. In any case, changing the Makefile to use "er" works for me.
<ulm> blueness: could to take a brief look at bug 497498? <ulm> blueness: in a nutshell, the emacs build system does both "paxctl -r temacs" and "setfattr -n user.pax.flags -v r temacs" <ulm> and if the kernel has both PT and XATTR flags enabled, then the executable cannot be started because of mismatching flags? [...] <ulm> is PT_PAX_FLAGS _and_ XATTR_PAX_FLAGS a supported configuration? <Zorry> you should only use one of them <Zorry> and the missmatch check in the kernel i think is removed in newer kernel or set softer <ulm> Zorry: do you know since what kernel version? <Zorry> i think it was 3.12.6-r2 <blueness> ulm, as Zorry said, use only one
Fixed in emacs-23.4-r6 and emacs-24.3-r2. No revbump, because it is a build failure. IIUC, this failure is of a transitional nature because PT_PAX_FLAGS will go away at some time. Therefore, I haven't reported it upstream. Please do so if you think that it should be fixed in the next Emacs release.
Fixed upstream: http://debbugs.gnu.org/cgi/bugreport.cgi?bug=19067 http://git.savannah.gnu.org/cgit/emacs.git/commit/?h=emacs-24&id=ed54567c7cf958bb5658f4b6da1b0b7decc1d31a
