Every next application start fails

[MarekMalevic]

Hello, I've compiled the game. When I start the game for the first time it works fine. But every other start fails (just black screen with no new error message, 100% of one CPU core used). I have to "killall -9 vdrift", delete all the settings (/home/myhomedir/.vdrift directory) to run the game again. But for me the default window mode is unusable.

OS: Debian Linux 2.6.22
latest nVidia drivers (all other OpenGL games works great)
AMD64 4200+ X2
2GB RAM
compiled with gcc 4.2
CXXFLAGS="-march=athlon64 -O3 -pipe"
CFLAGS="-march=athlon64 -O3 -pipe"
scons arch=a64
installed: /opt/vdrift
symlink to /usr/local/bin/vdrift

sucessful (first) start

Code:

BinReloc successfully initialized.
Executable path: /opt/vdrift/vdrift
Data dir: /opt/data
Localedir: /opt/share/locale
CONFIGFILE.Load: Couldn't find file:  /home/malevicovi/.vdrift/VDrift.config
No data_dir found in VDrift.config, using /opt/data
/opt/data/settings/VDrift.config not found. Attempting to load data from /opt/vdrift/data
Can't find the settings directory at "/home/malevicovi/.vdrift". Making a new one...
Missing /home/malevicovi/.vdrift/controls file, copying.
Found config file /home/malevicovi/.vdrift/VDrift.config.
No data_dir found in VDrift.config, using /opt/vdrift/data
Version of game: development-full
Skin name not found in config file...
/opt/share/locale
Directory /opt/vdrift/data/skins/SConscript/menus does not exist! Skin SConscript not loaded.
Warning: option-47 is missing its default value. Assuming "".
Run with -verbose for troubleshooting.
Run with -nosound to disable sound.
Run with -benchmark to play a replay and output benchmark data.
0 joystick(s) found:
Card supports: drawbuf8 auxbuf4 antialiasing anisotropy16 cubemapping shaders multitexturing32(4) texture_rectangle depth_texture shadow framebuffer_objects
Card does not support:
Fragment shaders enabled
Loaded shader package simple
Loaded shader package full
Loaded shader package full-noshadow
Loaded shader package blurpass
Loaded shader package depthgen
Framebuffer object complete
Framebuffer object complete
Obtained audio device:
Frequency: 44100
Format: 32784
Bits per sample: 16
Channels: 2
Silence: 0
Samples: 940
Size: 3760

not successful start

Code:

BinReloc successfully initialized.
Executable path: /home/malevicovi/src/vdrift/vdrift
Data dir: /home/malevicovi/src/data
Localedir: /home/malevicovi/src/share/locale
No data_dir found in VDrift.config, using /home/malevicovi/src/data
/home/malevicovi/src/data/settings/VDrift.config not found. Attempting to load data from /home/malevicovi/src/vdrift/data
Found config file /home/malevicovi/.vdrift/controls.
Found config file /home/malevicovi/.vdrift/VDrift.config.
No data_dir found in VDrift.config, using /home/malevicovi/src/vdrift/data
Version of game: development-full
Skin name not found in config file...
/home/malevicovi/src/share/locale
Directory /home/malevicovi/src/vdrift/data/skins/SConscript/menus does not exist! Skin SConscript not loaded.
Warning: option-47 is missing its default value. Assuming "".
Run with -verbose for troubleshooting.
Run with -nosound to disable sound.
Run with -benchmark to play a replay and output benchmark data.
0 joystick(s) found:
Card supports: drawbuf8 auxbuf4 antialiasing anisotropy16 cubemapping shaders multitexturing32(4) texture_rectangle depth_texture shadow framebuffer_objects
Card does not support:
Fragment shaders enabled
Loaded shader package simple
Loaded shader package full
Loaded shader package full-noshadow
Loaded shader package blurpass
Loaded shader package depthgen
Framebuffer object complete
Framebuffer object complete

Thanks a lot for help.
Marek

[MarekMalevic]

I tried to figure out which one of the files makes the problem. I realized that if I delete just the ~/.vdrift/controls.config file, the game can be started. Just to know more.

[thelusiv]

What version of the game have you compiled?

Have you looked at the controls.config to check for any problems, such as lines containing garbage data or something of that nature?

[MarekMalevic]

This is what I downloaded today and doesn't work for me:

vdrift-2007-12-26 Notes (2007-12-27 10:39)
vdrift-2007-12-26-data-rc1.zip Mirror 130865677 303 Platform-Independent .zip
vdrift-2007-12-26-src-rc1.tar.bz2

Right now I'm trying to find some more details. I'll post the results here.

[MarekMalevic]

The file itself is not the problem. I compiled the same version of VDrift (the latest release available today - as described in one of the previous posts) on another machine (32bit, the same OS). VDrift works here with exactly the same controls.config .

This means I have to debug the program tomorrow on the 64bit machine to find the thing. I will let you know afterwards.

[thelusiv]

Try compiling on your 64-bit box without optimizations. I'm not sure how likely this is to cause problems, it shouldn't but you never know. I am running VDrift fine on Ubuntu 7.10...can you post the output of

Code:

ldd build/vdrift

[MarekMalevic]

Once again I'm back to write to you how I solved my problem. I added some more couts to the code to see where exactly the program fails. The point _is_ in the file configfile.cpp, here:

Code:

CONFIGFILE::CONFIGFILE(string fname)
{
    //vars = NULL;
    
    SUPPRESS_ERROR = false;
    Load(fname);
}

After adding one cout like this:

Code:

CONFIGFILE::CONFIGFILE(string fname)
{
    //vars = NULL;
    
    SUPPRESS_ERROR = false;
    //workaround for the buggy gcc
    cout << "";
    Load(fname);
}

the program runs well. Writing some other types of code (not cout) here didn't work for me.

The workauround is not needed when:
1) compiled for 32bit (let's say not -march=athlon64)
or
2) compiled with different gcc (in my case gcc-4.1 (GCC) 4.1.3 20070831 (prerelease) (Debian 4.1.2-16)) in 64bit mode
or
3) copiled for 64bit without any optimization enabled (not even -O2)

The workaround is needed when:
1) using
gcc (GCC) 4.2.3 20071014 (prerelease) (Debian 4.2.2-3)
or
gcc (GCC) 4.2.3 20071123 (prerelease) (Debian 4.2.2-4)
2) while you want the optimizations to be enabled (-O2 or -O3)
3) compiling for the -march=athlon64

I'm not any C++ hacker but I would say it's some bug in 4.2 compilator (optimization for athlon64).

For thelusiv - you were right. And my ldd vdrift is:

libSDL-1.2.so.0 => /usr/lib/libSDL-1.2.so.0 (0x00002b8e1471c000)
libGL.so.1 => /usr/lib/libGL.so.1 (0x00002b8e149d2000)
libGLU.so.1 => /usr/lib/libGLU.so.1 (0x00002b8e14ba0000)
libSDL_image-1.2.so.0 => /usr/lib/libSDL_image-1.2.so.0 (0x00002b8e14e22000)
libSDL_net-1.2.so.0 => /usr/lib/libSDL_net-1.2.so.0 (0x00002b8e1503f000)
libSDL_gfx.so.4 => /usr/lib/libSDL_gfx.so.4 (0x00002b8e15242000)
libvorbisfile.so.3 => /usr/lib/libvorbisfile.so.3 (0x00002b8e15353000)
libstdc++.so.6 => /usr/lib/libstdc++.so.6 (0x00002b8e1555b000)
libm.so.6 => /lib/libm.so.6 (0x00002b8e15863000)
libgcc_s.so.1 => /lib/libgcc_s.so.1 (0x00002b8e15ae4000)
libc.so.6 => /lib/libc.so.6 (0x00002b8e15cf3000)
libpthread.so.0 => /lib/libpthread.so.0 (0x00002b8e16051000)
libasound.so.2 => /usr/lib/libasound.so.2 (0x00002b8e1626c000)
libdl.so.2 => /lib/libdl.so.2 (0x00002b8e1654c000)
libdirectfb-0.9.so.25 => /usr/lib/libdirectfb-0.9.so.25 (0x00002b8e16750000)
libfusion-0.9.so.25 => /usr/lib/libfusion-0.9.so.25 (0x00002b8e169b0000)
libdirect-0.9.so.25 => /usr/lib/libdirect-0.9.so.25 (0x00002b8e16bb7000)
libvga.so.1 => /usr/lib/libvga.so.1 (0x00002b8e16dc7000)
libGLcore.so.1 => /usr/lib/libGLcore.so.1 (0x00002b8e16f2e000)
libnvidia-tls.so.1 => /usr/lib/tls/libnvidia-tls.so.1 (0x00002b8e17a8f000)
libXext.so.6 => /usr/lib/libXext.so.6 (0x00002b8e17b90000)
libX11.so.6 => /usr/lib/libX11.so.6 (0x00002b8e17ca1000)
libpng12.so.0 => /usr/lib/libpng12.so.0 (0x00002b8e17eab000)
libz.so.1 => /usr/lib/libz.so.1 (0x00002b8e180cf000)
libvorbis.so.0 => /usr/lib/libvorbis.so.0 (0x00002b8e182e6000)
/lib64/ld-linux-x86-64.so.2 (0x00002b8e144fe000)
libXau.so.6 => /usr/lib/libXau.so.6 (0x00002b8e18512000)
libXdmcp.so.6 => /usr/lib/libXdmcp.so.6 (0x00002b8e18614000)
libogg.so.0 => /usr/lib/libogg.so.0 (0x00002b8e1871a000)

[thelusiv]

I was right! Thanks for helping figure that out. I think it best to avoid adding compiler bug workarounds to the code base. Maybe this bug could be reported to the GCC project somehow?