Forums

Full Version: Every next application start fails
You're currently viewing a stripped down version of our content. View the full version with proper formatting.
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
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.
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?
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.
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.
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
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:
Quote: 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)
I was right! Smile 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?