Bug 147503 - loki games don't run since 2.6.8
loki games don't run since 2.6.8
Status: CLOSED ERRATA
Product: Fedora
Classification: Fedora
Component: kernel (Show other bugs)
3
i386 Linux
medium Severity medium
: ---
: ---
Assigned To: Dave Jones
:
: 147501 (view as bug list)
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2005-02-08 11:59 EST by Jürgen Botz
Modified: 2015-01-04 17:16 EST (History)
7 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2005-09-28 04:15:48 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Jürgen Botz 2005-02-08 11:59:14 EST
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@lokigames.com
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:
Comment 1 Dave Jones 2005-02-08 14:13:26 EST
Ingo, any ideas ?
Comment 2 Dave Jones 2005-02-08 18:26:09 EST
*** Bug 147501 has been marked as a duplicate of this bug. ***
Comment 3 Jürgen Botz 2005-02-09 03:25:19 EST
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 02:01:11 EST
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?
Comment 5 Joe Orton 2005-02-26 18:58:27 EST
CivCTP is broken similarly.  Tried using all the sysctls as above and
also:

setarch i386 -L civctp 

2.6.10-1.741_FC3
Comment 6 Sitsofe Wheeler 2005-02-27 08:06:36 EST
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 18:01:47 EST
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 18:04:49 EST
even including setting /proc/sys/vm/legacy_va_layout to 1 ?

Comment 9 Jürgen Botz 2005-02-27 18:29:42 EST
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 17:48:10 EST
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-26 21:02:17 EST
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 03:09:06 EDT
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 12:15:32 EDT
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-11 21:20:01 EDT
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 13:58:29 EDT
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.