I'm new to bygfoot and the version 1.9.6 is the first one I'm playing. I think there's a bug in this game: I'm doing nothing (except of starting the game and pressing the "next week" button *). The match of my team is simulated, and then all the rest of the matches. And then the game crashes, with "Segmentation fault" error (I play the game on my Arch Linux system).
I've compiled the game with the following options:
-Os -march=pentium4 -mfpmath=sse -fomit-frame-pointer -s -pipe
I have also tried without -fomit-frame-pointer (although it shouldn't cause any bugs; I use gcc 3.4.x and the game is written in C), but it didn't help.
* I'm playing the Polish version of the game. The button I press is the one, that causes the time to pass by, so the next match is played.
1.9.6 The game crashes after the first week
Thanks for reporting the problem.
I've done a quick test on Debian sid with bygfoot 1.9.6, gcc 3.4.6 and
CFLAGS="-Os -march=athlon-xp -mfpmath=sse -fomit-frame-pointer -s -pipe"
using a Polish locale for compiling and running the game. I cannot replicate the segfault. I can't test -march=pentium4, and I don't have SSE2.
Have you tried compiling without any special CFLAGS? At least then we can try and work out if the crash is related to the compiler switches.
What exact version of gcc 3.4 are you using? When you say you are running the Polish version, do you mean running in the Polish language, selecting a Polish team, or both?
I've done a quick test on Debian sid with bygfoot 1.9.6, gcc 3.4.6 and
CFLAGS="-Os -march=athlon-xp -mfpmath=sse -fomit-frame-pointer -s -pipe"
using a Polish locale for compiling and running the game. I cannot replicate the segfault. I can't test -march=pentium4, and I don't have SSE2.
Have you tried compiling without any special CFLAGS? At least then we can try and work out if the crash is related to the compiler switches.
What exact version of gcc 3.4 are you using? When you say you are running the Polish version, do you mean running in the Polish language, selecting a Polish team, or both?
mark's tests should rule out this possibility, but you never know with computers: you could also try running the game in a different language, e.g. "bygfoot -L en" or "bygfoot -L de". also, if you've got a savegame from the first week that always crashes, you could send it to me by email and i'll check it.
gyözö
gyözö
Press any key to continue or any other key to quit.
All right, so let's start with this stuff. The tests, that I have performed:
1) I tried to run the game with "bygfoot -L en", but it crashed.
After this test I ran the game as usual ("bygfoot"), so most of the messages were in Polish, and I had chosen some player name, some team, and then I saved the game. Then I pressed the "Next week" button. The game crashed, so I ran it again and loaded the saved game, and the crash happened again. All the following test were done with the same scheme: start the game, load the saved game, and then just press the "Next week" button.
2) I tried to remove all the compilation/linking flags that I had used before. The game built, and ran well. No crash happened this time.
3) I have successfully added the following compiler flags: -Os, -fomit-frame-pointer, -s, -pipe. I have also added the following linker flags: -s, -z combreloc. Still no crashes.
4) Then I have tried to add the -march=pentium4 flag. The game crashed.
5) So I have tried to add the -march=pentium3 flag. The game crashed.
6) Then I decided to try with the -march=i686 flag. The game didn't crash.
At this moment I decided to take a closer look at my gcc. I did
and I got
After replacing -march=i686 with -march=pentium3 I got:
Since the difference was the -mmmx and -msse flags (perhaps there are also some other differencies too...), I decided to perform the next test.
7) I tried to compile the game with the -march=i686 -mmmx flags. The game didn't crash.
8) So I tried to compile the game with the -march=i686 -mmmx -msse flags. The game crashed.
To sum it up: I think that "the winner" is -msse (-msse2, etc.). I don't know if the error is in the game code, in my compiler, or somewhere else. I'm not an expert in such sort of things. I just know, that I have successfully built and run many programs using the -march=pentium4 flag.
(BTW: I have performed all these test on my Celeron machine. I have also an older Celeron in my laptop, and this older one is P3, but I haven't performed any test on it. However, I could, if you'd like me to do it.)
1) I tried to run the game with "bygfoot -L en", but it crashed.
After this test I ran the game as usual ("bygfoot"), so most of the messages were in Polish, and I had chosen some player name, some team, and then I saved the game. Then I pressed the "Next week" button. The game crashed, so I ran it again and loaded the saved game, and the crash happened again. All the following test were done with the same scheme: start the game, load the saved game, and then just press the "Next week" button.
2) I tried to remove all the compilation/linking flags that I had used before. The game built, and ran well. No crash happened this time.
3) I have successfully added the following compiler flags: -Os, -fomit-frame-pointer, -s, -pipe. I have also added the following linker flags: -s, -z combreloc. Still no crashes.
4) Then I have tried to add the -march=pentium4 flag. The game crashed.
5) So I have tried to add the -march=pentium3 flag. The game crashed.
6) Then I decided to try with the -march=i686 flag. The game didn't crash.
At this moment I decided to take a closer look at my gcc. I did
Code: Select all
$ touch empty.c
$ gcc -v -S -Q empty.c -march=i686Code: Select all
Reading specs from /usr/lib/gcc/i686-pc-linux-gnu/3.4.3/specs
Configured with: ../gcc-3.4.3/configure --prefix=/usr --enable-shared --enable-languages=c,c++,objc --enable-threads=posix --enable-__cxa_atexit
Thread model: posix
gcc version 3.4.3
/usr/libexec/gcc/i686-pc-linux-gnu/3.4.3/cc1 -v empty.c -dumpbase empty.c -march=i686 -auxbase empty -version -o empty.s
ignoring nonexistent directory "/usr/lib/gcc/i686-pc-linux-gnu/3.4.3/../../../../i686-pc-linux-gnu/include"
#include "..." search starts here:
#include <...> search starts here:
/usr/local/include
/usr/lib/gcc/i686-pc-linux-gnu/3.4.3/include
/usr/include
End of search list.
GNU C version 3.4.3 (i686-pc-linux-gnu)
compiled by GNU C version 3.4.3.
GGC heuristics: --param ggc-min-expand=64 --param ggc-min-heapsize=64468
options passed: -v -march=i686 -auxbase
options enabled: -feliminate-unused-debug-types -fpeephole -ffunction-cse
-fkeep-static-consts -fpcc-struct-return -fgcse-lm -fgcse-sm -fgcse-las
-fsched-interblock -fsched-spec -fsched-stalled-insns
-fsched-stalled-insns-dep -fbranch-count-reg -fcommon -fargument-alias
-fzero-initialized-in-bss -fident -fmath-errno -ftrapping-math -m80387
-mhard-float -mno-soft-float -mieee-fp -mfp-ret-in-387
-maccumulate-outgoing-args -mno-red-zone -mtls-direct-seg-refs -mtune=i686
-march=i686
Execution times (seconds)
parser : 0.01 (100%) usr 0.00 ( 0%) sys 0.00 ( 0%) wall
TOTAL : 0.01 0.00 0.01Code: Select all
Reading specs from /usr/lib/gcc/i686-pc-linux-gnu/3.4.3/specs
Configured with: ../gcc-3.4.3/configure --prefix=/usr --enable-shared --enable-languages=c,c++,objc --enable-threads=posix --enable-__cxa_atexit
Thread model: posix
gcc version 3.4.3
/usr/libexec/gcc/i686-pc-linux-gnu/3.4.3/cc1 -v empty.c -dumpbase empty.c -march=pentium3 -auxbase empty -version -o empty.s
ignoring nonexistent directory "/usr/lib/gcc/i686-pc-linux-gnu/3.4.3/../../../../i686-pc-linux-gnu/include"
#include "..." search starts here:
#include <...> search starts here:
/usr/local/include
/usr/lib/gcc/i686-pc-linux-gnu/3.4.3/include
/usr/include
End of search list.
GNU C version 3.4.3 (i686-pc-linux-gnu)
compiled by GNU C version 3.4.3.
GGC heuristics: --param ggc-min-expand=64 --param ggc-min-heapsize=64468
options passed: -v -march=pentium3 -auxbase
options enabled: -feliminate-unused-debug-types -fpeephole -ffunction-cse
-fkeep-static-consts -fpcc-struct-return -fgcse-lm -fgcse-sm -fgcse-las
-fsched-interblock -fsched-spec -fsched-stalled-insns
-fsched-stalled-insns-dep -fbranch-count-reg -fcommon -fargument-alias
-fzero-initialized-in-bss -fident -fmath-errno -ftrapping-math -m80387
-mhard-float -mno-soft-float -mieee-fp -mfp-ret-in-387
-maccumulate-outgoing-args -mmmx -msse -mno-red-zone -mtls-direct-seg-refs
-mtune=pentium3 -march=pentium3
Execution times (seconds)
parser : 0.00 ( 0%) usr 0.00 ( 0%) sys 0.01 (50%) wall
TOTAL : 0.01 0.00 0.027) I tried to compile the game with the -march=i686 -mmmx flags. The game didn't crash.
8) So I tried to compile the game with the -march=i686 -mmmx -msse flags. The game crashed.
To sum it up: I think that "the winner" is -msse (-msse2, etc.). I don't know if the error is in the game code, in my compiler, or somewhere else. I'm not an expert in such sort of things. I just know, that I have successfully built and run many programs using the -march=pentium4 flag.
(BTW: I have performed all these test on my Celeron machine. I have also an older Celeron in my laptop, and this older one is P3, but I haven't performed any test on it. However, I could, if you'd like me to do it.)
Thanks for doing all those tests! Yes, SSE does seem to be the problem.TPJ wrote:To sum it up: I think that "the winner" is -msse (-msse2, etc.).
I've had a quick look on gcc.gnu.org and there are some SSE bugs that are fixed in later versions of gcc 3.4. One of them might explain why you got a crash with -msse but without -mfpmath. The compiler shouldn't use SSE unless you set the mfpmath flag.
I would recommend that you upgrade to a later version of gcc 3.4. For now, I'd stick with your plain i686 build. (You can try specifying -mno-sse instead of -mfpmath=sse. That might work.)
I would usually hesitate to blame the compiler but there is plenty of evidence in this case, especially as my builds with gcc 3.4.6 worked fine.
Mark
I have tested the game with GCC 3.4.6, 4.0.3 and 4.1.1 (the newest versions in the branches 3.4, 4.0 and 4.1), and all of them have worked perfectly (-march=pentium4 -msse2 -mfpmath=sse). So I think it was a gcc bug, not a bygfoot one.
However, I have to say, that I have compiled many programs with the gcc 3.4.3, with CFLAGS set to "-march=pentium4 -msse2 -mfpmath=sse", and I have experienced no errors.
My conclusion is that bygfoot shouldn't be compiled with the gcc version 3.4.3 and any -msse flags (-msse2, etc.).
However, I have to say, that I have compiled many programs with the gcc 3.4.3, with CFLAGS set to "-march=pentium4 -msse2 -mfpmath=sse", and I have experienced no errors.
My conclusion is that bygfoot shouldn't be compiled with the gcc version 3.4.3 and any -msse flags (-msse2, etc.).