Summary: | app-editors/emacs-23.2-r2 fails to build (won't "dump") on arm | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | Josh Parsons <josh.parsons> |
Component: | Current packages | Assignee: | Emacs project <emacs> |
Status: | RESOLVED NEEDINFO | ||
Severity: | major | CC: | arm |
Priority: | High | ||
Version: | unspecified | ||
Hardware: | ARM | ||
OS: | Linux | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- | |
Attachments: |
complete build.log for the failed emerge
Kernel config - gentoo hardened. |
Description
Josh Parsons
2010-11-11 03:45:16 UTC
Created attachment 253951 [details]
complete build.log for the failed emerge
That's an old issue (and I thought is was fixed). You may have a look at these: <http://lkml.org/lkml/2007/10/23/435> <http://debbugs.gnu.org/cgi/bugreport.cgi?bug=900> Bug 236579 What is the output of the following command? $ cat /proc/sys/kernel/randomize_va_space I'm unable to reproduce this, I used the same CFLAGS and USE-flags but could not trigger it. # cat /proc/sys/kernel/randomize_va_space 1 # cat /proc/sys/kernel/randomize_va_space 2 Oh, and I made a mistake in my initial report. Earlier versions of emacs no longer build for me on the affected machine, though I'm not sure what I changed to cause this. I am running a fairly recent kernel: gentoo-sources-2.6.36. Previous builds would have been under a different kernel. Oh, and CONFIG_COMPAT_BRK is not set for my kernel if that makes a difference. I assumed that the relevant difference between the machine which is having trouble and my other machines was architecture. It may be that the difference is that they are not running a 2.6.36 kernel (which they aren't), or there is some subtle configuration difference. (In reply to comment #4) > # cat /proc/sys/kernel/randomize_va_space > 2 Does Emacs build if you set this to 0 or 1? ("echo 0 >/proc/sys/kernel/randomize_va_space", and verify that it really contains that value afterwards.) But in principle, Emacs should do that by itself, i.e. before dumping, it should set a different process personality and then execvp itself. See lines 879 and following in emacs.c: #ifdef HAVE_PERSONALITY_LINUX32 if (!initialized && (strcmp (argv[argc-1], "dump") == 0 || strcmp (argv[argc-1], "bootstrap") == 0) && ! getenv ("EMACS_HEAP_EXEC")) { /* Set this so we only do this once. */ putenv("EMACS_HEAP_EXEC=true"); /* A flag to turn off address randomization which is introduced in linux kernel shipped with fedora core 4 */ #define ADD_NO_RANDOMIZE 0x0040000 personality (PER_LINUX32 | ADD_NO_RANDOMIZE); #undef ADD_NO_RANDOMIZE execvp (argv[0], argv); /* If the exec fails, try to dump anyway. */ perror ("execvp"); } #endif /* HAVE_PERSONALITY_LINUX32 */ > I am running a fairly recent kernel: gentoo-sources-2.6.36. Previous builds > would have been under a different kernel. > > Oh, and CONFIG_COMPAT_BRK is not set for my kernel if that makes a > difference. I can't speak for arm, but on amd64 that combination (2.6.36 without COMPAT_BRK) works. Builds OK with /proc/sys/kernel/randomize_va_space=1 I can confirm this problem as well as the solution of disabling address randomization on a SheevaPlug ARM system with emacs-23.3-r1 and vanilla-sources-2.6.37.6. It used to work before, and was a kernel update in between (from 2.6.32.9 if I remember correctly), so I wonder whether this might really be kernel problem along the lines of disabling randomization by changing personality being broken. I'll try to investigate this a bit more when I find time. That's the sort of problem that usually needs to be debugged on the platform where it fails. Any help on this bug will be appreciated. Created attachment 402976 [details]
Kernel config - gentoo hardened.
It also fails on AMD64 hardened kernel (Note: Kernel version linux-3.19.6-hardened-r1. Only kernel is hardened. I'm using normal systemd profile). It complains about exec-shield and segfaults after complaining.
I think it is related on grsecurity setting, so I attach my kernel config
and here is my dmesg.
[423293.428710] temacs[15435]: segfault at af7008 ip 00000373135c4970 sp 000003af446f5cb8 error 4 in libc-2.20.so[37313533000+18f000]
[423537.191298] temacs[20282]: segfault at af7008 ip 0000032846f06970 sp 000003908abfbaa8 error 4 in libc-2.20.so[32846e75000+18f000]
(In reply to perillamint from comment #9) Different architecture, and given the time that has passed, it is likely a different issue. Please file a new bug and attach your build.log there. No progress since 2011. Closing. For what it's worth, if anyone is following this, the hardware on which I had the problem gave up the ghost in Jan 2015. I had for 5 years had an init script that contained "echo 1 >/proc/sys/kernel/randomize_va_space". |