From Bugzilla Helper: User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.5) Gecko/20041228 Firefox/1.0 Fedora/1.0-8 Description of problem: loki games won't start since kernel 2.6.8, at least redhat kernel, haven't tested vanilla kernel yet. None of the following settings (all of which have been suggeste for binary backward compatibility in various places) seem to make a difference: export LD_ASSUME_KERNEL=2.4.19 {cmd} setarch i386 {cmd} sysctl -w kernel.exec-shield=0 sysctl -w kernel.exec-shield-randomize=0 sysctl -w vm.legacy_va_layout=1 sysctl -w kernel.vdso=0 For example Loki's "Sid Meyer's Alpha Centauri" (smac) gives the following (no change with any/all of the above: [jbotz@tango smac]$ ./smac BUG! (Segmentation Fault) Going down hard... Sid Meier's Alpha Centauri 6.0a Built with glibc-2.1 on x86 Stack dump: { 0x837dcde 0x835cc24 0x835ca8b 0x83568bd 0x8356a3e 0x834a4cf 0x8341b89 0x8341c68 0x8297f4b 0x842202d 0x8048111 } Please send a full bug report, along with the contents of autosave to: support Unable to execute loki_qagent - exiting This has been true since FC2 with all redhat kernels I've tried since 2.6.8. Version-Release number of selected component (if applicable): kernel-2.6.8-1.521 How reproducible: Always Steps to Reproduce: 1. boot an FC2 system w/ kernel >= 2.6.8 2. run a loki games binary (i.e. 'smac') 3. Additional info:
Ingo, any ideas ?
*** Bug 147501 has been marked as a duplicate of this bug. ***
Ok, I took the SRPM for kernel-2.6.9-1.11_FC2 and rebuilt it without /any/ RedHat patches and ended up with a kernel that /does/ run 'smac'. I did it this way rather than building from kernel.org source to use the same .config, but one variable is that the .config is not exactly the same, because there were two config settings I didn't have the "RedHat answer" to... 1) NET_SCHED (I chose '1') 2) 4KSTACKS (I chose 'N') 4KSTACKS looks like a candidate, so I'm going to try again with that set.
The culprit is exec-shield. I took the 2.6.10-1.12_FC2 SRPM, commented out the exec-shield patch, and rebuilt it, and loki games ran fine with the resulting kernel. But as stated in the original bug report, merely turning exec-shield off with the appropriate sysctl commands or via /proc does *not* help. Makes you wonder if 'sysctl -w kernel.exec-shield=0', etc., actually do anything at all? Mingo?
CivCTP is broken similarly. Tried using all the sysctls as above and also: setarch i386 -L civctp 2.6.10-1.741_FC3
I wonder whether the actual problem is randomised VM mappings. Does doing: sysctl -w kernel.exec-shield-randomize=0 help? If not does anything on http://dag.wieers.com/howto/compatibility/ help?
No, none of the backwards-compat sysctl's make any difference for me. I rebuilt the .766 kernel with patches 511-513 removed and Civ worked again.
even including setting /proc/sys/vm/legacy_va_layout to 1 ?
Folks, I already went through all that. None of the compatibility sysctl/proc settings make a difference. Only removing the exec-shield patch entirely solves the problem. See comments #1-4.
Same issue on Red Hat Enterprise Linux 4 WS with kernel-2.6.9-5.0.3. EL. And also neither of the compatibility settings has any effect.
I don't know about CivCTP, but I have SMAC and Heroes3 both working on FC4t1 using the MALLOC_CHECK=0 cmd mentioned in Dag's page. Heroes3 works perfectly, while SMAC is opened at a funny resolution and best used in windowed mode. The important part is, they work.
That was MALLOC_CHECK_=0 actually, and while it worked for a while, I updated something and it stopped. Unfortunately, I didn't write down the exact configuration. However, I just installed FC4t2 and updated the kernel (2.6.11-1.1234_FC4), xorg (xorg-x11-6.8.2-20), installed mplayer and gstreamer-plugins-extras-audio and mplayer and requirements from Freshrpms (built for FC3) and now they both work. SMAC still has the strange resolution problem, and adding in various resolutions under xorg.conf for the 16bit X server didn't fix it as I hoped, but they still work.
MALLOC_CHECK_=0 does not work on RHEL 4. And it would be quite strange if it works. The Loki binaries are all static (some of the dynamical binaries that are available segfaults immediately when I tried to run them with recent Glibc). It guess that the new FC4 kernel solves the problem.
Confirmed here that civctp works out of the box with 2.6.11-1.1369_FC4 - with exec-shield still enabled. (and MALLOC_CHECK_ unset)
An update has been released for Fedora Core 3 (kernel-2.6.12-1.1372_FC3) which may contain a fix for your problem. Please update to this new kernel, and report whether or not it fixes your problem. If you have updated to Fedora Core 4 since this bug was opened, and the problem still occurs with the latest updates for that release, please change the version field of this bug to 'fc4'. Thank you.