linux x86_64 segmentation fault

[GoogleCodeExporter]

What steps will reproduce the problem?
1. "make" on kubuntu 10.10 x86_64
2.
3.

What is the expected output? What do you see instead?
1. sys_unix.c fails to compile: line 799 #error Unknown arch
(adding 
#elif defined __x86_64__ 
    return va( "%s.mp.x86_64.so", name );
solves this)
2. SDL_config_minimal.h redefines typedef unsigned int size_t which should be 
typedef long unsigned int size_t
3. does compile with noted changes, but still gives segmentation fault, without 
any additional output.

What version of the product are you using? On what operating system?
svn trunk/ bzzwolfsp-read-only checkout 1 hour ago. Running (K)Ubuntu 10.10 on 
64 bit system.

Please provide any additional information below.

Original issue reported on code.google.com by aschilham@gmail.com on 22 Feb 2011 at 10:03

[GoogleCodeExporter]

I used the ioquake3 sys/ files which should be x86_64 bit compatible, but the 
makefile and the other parts probably arent (yet)

Original comment by frederik...@gmail.com on 23 Feb 2011 at 8:32

[GoogleCodeExporter]

So is there no way currently to build bzzwolfsp on x86_64? (I have the same 
problem)

Original comment by johannes...@gmail.com on 13 Mar 2011 at 3:52

[GoogleCodeExporter]

I'm working on it; a lot of code needs to be fixed but I'm almost there. 
Hopefully the owner of this code.google project will accept my changes. If not, 
I will start a new one.

Original comment by aschilham@gmail.com on 14 Mar 2011 at 9:24

[GoogleCodeExporter]

sounds good aschilham, once it works, I'll give you svn acces, so you can 
commit !

Original comment by frederik...@gmail.com on 14 Mar 2011 at 9:41

[GoogleCodeExporter]

Any progress on this? I'm stuck on a segfault in FS_PathCmp... Any ideas? 
Aschilham?

Original comment by vtr...@gmail.com on 29 Apr 2011 at 8:42

[GoogleCodeExporter]

Compilation is fine for me, and the game might be running fine, but I cannot 
see it: There is some problem with the lighting/rendering because the scenes 
are almost completely dark. I'm stuck with this problem since March. 

Original comment by aschilham@gmail.com on 30 Apr 2011 at 11:27

[GoogleCodeExporter]

yeah the game is pretty dark for me too, I've tweaked some r_ cvars to make it 
brighter

I havent worked on it lately, didn't have much free time and I'm stuck with the 
player animations for now

Original comment by frederik...@gmail.com on 2 May 2011 at 12:01

[GoogleCodeExporter]

Well that's different: in 32 bits the lighting is acceptable, but in my 64 bits 
version I literally cannot see anything (apart from the 'slides' in the intro 
scene or some special lights like the sparks in the torture chamber). I cannot 
figure out if all the colors are wrong and everything is rendered as black, or 
if the direction of the light or sight is inverted, or if shadows are rendered 
in front of the objects or whatever. Any an all suggestions are welcome. 

@vtr: Try if changing the first line of FS_PathCmp from "int c1,c2;" to "char 
c1,c2;" solves the problem. If not, the problem is not in FS_PathCmp but 
earlier in the filling of the strings.

Original comment by aschilham@gmail.com on 2 May 2011 at 3:40

[GoogleCodeExporter]

Problem not only in FS_PathCmp, but also in paksort function. In arguments to 
qsort function you need to replace 4 with sizeof(char*)

Original comment by iSage....@gmail.com on 22 May 2011 at 10:11

[GoogleCodeExporter]

same problem here on archlinux, after adding defines it compiles but segfaults. 
data files are in place

[maci@T61 debug-linux-x86_64]$ gdb wolfsp.x86_64 
GNU gdb (GDB) 7.3.1
Copyright (C) 2011 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-unknown-linux-gnu".
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>...
Reading symbols from 
/home/maci/Desktop/bzzwolfsp-read-only/build/debug-linux-x86_64/wolfsp.x86_64...
done.
(gdb) run
Starting program: 
/home/maci/Desktop/bzzwolfsp-read-only/build/debug-linux-x86_64/wolfsp.x86_64 
[Thread debugging using libthread_db enabled]

Program received signal SIGSEGV, Segmentation fault.
0x00007ffff6db823c in ?? () from /lib/libc.so.6
(gdb) bt
#0  0x00007ffff6db823c in ?? () from /lib/libc.so.6
#1  0x0000000000468305 in Q_strncpyz (dest=0x15ce440 "", 
    src=0xffffffffffffea8e <Address 0xffffffffffffea8e out of bounds>, 
    destsize=256) at src/game/q_shared.c:837
#2  0x000000000052ee36 in Sys_SetBinaryPath (
    path=0xffffffffffffea8e <Address 0xffffffffffffea8e out of bounds>)
    at src/sys/sys_main.c:60
#3  0x000000000052f92d in main (argc=1, argv=0x7fffffffe7e8)
    at src/sys/sys_main.c:617

Original comment by maci.s...@gmail.com on 30 Nov 2011 at 6:06

[GoogleCodeExporter]

These last problems are because certain functions don't have prototypes 
defined.  I've fixed that and ran into issues with memset causing a crash.  I 
can provide a patch that fixes current SVN up to the point where I'm getting 
crashes.

Original comment by sa666...@gmail.com on 8 Dec 2011 at 10:25

[GoogleCodeExporter]

that would be great !

Original comment by frederik...@gmail.com on 9 Dec 2011 at 7:32

[GoogleCodeExporter]

working on it!

Original comment by frederik...@gmail.com on 17 Jan 2012 at 3:30

• Changed state: Accepted

[GoogleCodeExporter]

the problem is that a 64bit client cannot connect to a 32bit server (and vice 
versa) without modifications in the network code, if I understand the problem 
correctly, so making the game compile under 64bit isn't a huge deal, but 
keeping it compatible with other architectures is

Original comment by frederik...@gmail.com on 18 Jan 2012 at 5:13

[GoogleCodeExporter]

(temporary) workaround: compile it 32 bit.

replace the line "COMPILE_ARCH=$(shell uname -m | sed -e s/i.86/i386/)" in the 
makefile by "COMPILE_ARCH=i386". Works for me on Fedora 16 x86_64.

Original comment by r...@rolffokkens.nl on 5 Feb 2012 at 11:20

[GoogleCodeExporter]

thanks for the info ! I'll test it asap on rhel and centos 64bit

Original comment by frederik...@gmail.com on 5 Feb 2012 at 5:56

[GoogleCodeExporter]

When attempting the workaround on a 64bit Fedora 16, I get: 

/usr/bin/ld: cannot find -lsupc++
collect2: ld returned 1 exit status

I probably need to install some 32 bit c++ lib package but yum search cant find 
it.

Original comment by richard....@gmail.com on 8 Feb 2012 at 10:13

[GoogleCodeExporter]

search for libstdc++-devel-4.1.2-51.el5.i386 (this is an example from a redhat 
5 installation)

Original comment by frederik...@gmail.com on 10 Feb 2012 at 7:53

[GoogleCodeExporter]

So if I understand correctly, there are basicly two 64bit issues.   Issue 1 is 
that the client itself does not support 64 bit's and issue 2 is that a 64bit 
client could not connect to a 32bit server and vice versa.

But is there any hope of getting issue 2 fixed untill 1 is complete?  Also, 
going ahead with issue 1 would make SP players like myself extreemly happy 
campers :)

Original comment by richard....@gmail.com on 18 Feb 2012 at 4:47

[GoogleCodeExporter]

So the workaround from rolf doesn't work for you ?

There's always hope ;) When I have time to focus on this issue I hope I'm able 
to fix it, but currently there is so much to be done and so less time, so it 
will take a while before I get my hands on it.

Original comment by frederik...@gmail.com on 18 Feb 2012 at 5:10

[GoogleCodeExporter]

Yes, I can build and run 32bit binaries just fine.   My problem is that I 
really dont want to have to install all those 32bit libraries needed for this 
to work...
Makes my system more complex than it has to be :)

Original comment by richard....@gmail.com on 18 Feb 2012 at 6:35

[GoogleCodeExporter]

Fixed in latest trunk revision 1331 (Full 64 bit support on all platforms)

Original comment by M4N4T4RMS on 29 Dec 2013 at 4:19

• Changed state: Fixed