Bug 147503 - loki games don't run since 2.6.8
Summary: loki games don't run since 2.6.8
Alias: None
Product: Fedora
Classification: Fedora
Component: kernel
Version: 3
Hardware: i386
OS: Linux
Target Milestone: ---
Assignee: Dave Jones
QA Contact:
: 147501 (view as bug list)
Depends On:
TreeView+ depends on / blocked
Reported: 2005-02-08 16:59 UTC by Jürgen Botz
Modified: 2015-01-04 22:16 UTC (History)
7 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Last Closed: 2005-09-28 08:15:48 UTC

Attachments (Terms of Use)

Description Jürgen Botz 2005-02-08 16:59:14 UTC
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:
Please send a full bug report,
along with the contents of autosave to: support@lokigames.com
Unable to execute loki_qagent - exiting

This has been true since FC2 with all redhat kernels I've tried since

Version-Release number of selected component (if applicable):

How reproducible:

Steps to Reproduce:
1. boot an FC2 system w/ kernel >= 2.6.8
2. run a loki games binary (i.e. 'smac')

Additional info:

Comment 1 Dave Jones 2005-02-08 19:13:26 UTC
Ingo, any ideas ?

Comment 2 Dave Jones 2005-02-08 23:26:09 UTC
*** Bug 147501 has been marked as a duplicate of this bug. ***

Comment 3 Jürgen Botz 2005-02-09 08:25:19 UTC
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.

Comment 4 Jürgen Botz 2005-02-14 07:01:11 UTC
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?


Comment 5 Joe Orton 2005-02-26 23:58:27 UTC
CivCTP is broken similarly.  Tried using all the sysctls as above and

setarch i386 -L civctp 


Comment 6 Sitsofe Wheeler 2005-02-27 13:06:36 UTC
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?

Comment 7 Joe Orton 2005-02-27 23:01:47 UTC
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.

Comment 8 Dave Jones 2005-02-27 23:04:49 UTC
even including setting /proc/sys/vm/legacy_va_layout to 1 ?

Comment 9 Jürgen Botz 2005-02-27 23:29:42 UTC
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.

Comment 10 Yue Shi Lai 2005-03-03 22:48:10 UTC
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.

Comment 11 Aaron Kurtz 2005-03-27 02:02:17 UTC
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.

Comment 12 Aaron Kurtz 2005-04-12 07:09:06 UTC
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.

Comment 13 Yue Shi Lai 2005-04-24 16:15:32 UTC
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.

Comment 14 Joe Orton 2005-06-12 01:20:01 UTC
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)

Comment 15 Dave Jones 2005-07-15 17:58:29 UTC
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.

Note You need to log in before you can comment on or make changes to this bug.