Segfault on start on Debian Unstable

[zx64]

Debian Sid (glibc 2.3.2.ds1-22, gcc 3.3.6. 3.4.3 and 4.0.0).

Full version and demo (v1.2.1) crash on starting. Backtrace info:

VERSION : linux-full-1.2.1

retAddress = 0x808f860
retAddress = 0x808f18e
retAddress = 0x807872f
retAddress = 0x815d7ba
retAddress = 0x80bfc74
retAddress = 0x804d851
retAddress = 0x80ba03b
retAddress = 0x80ba1c9
retAddress = 0x80a6466
retAddress = 0xb7c33e36
retAddress = 0x804cdc1

(the last few lines are the same for the demo)

Despite this "minor" set back, thanks for the Linux port.

Euan.

[John]

This looks like the same call stack as Frodo42. Please could you include the VERSION line from the backtrace, so that I can resolve the symbols, thanks.

[zx64]

linux-full-1.2.1 and linux-demo-1.2.1.
I don't have access to the CD to reinstall the full version right now, so here's the backtrace from the demo:

VERSION : linux-demo-1.2.1

#0 0xb7cc53ae in waitpid () from /lib/tls/libc.so.6
#1 0xb7c5ad12 in system () from /lib/tls/libc.so.6
#2 0x08084f28 in ?? ()
#3 0x08085222 in ?? ()
#4 0x08085040 in ?? ()
#5 <signal handler called>
#6 0x08087d5a in ?? ()
#7 0x00000000 in ?? ()
#8 0x08171763 in std::basic_streambuf<wchar_t, std::char_traits<wchar_t> >::_S_pback_size ()
#9 0x081f9f18 in ?? ()
#10 0xbffff43c in ?? ()
#11 0x08088140 in ?? ()
#12 0x00000008 in ?? ()
#13 0x08171763 in std::basic_streambuf<wchar_t, std::char_traits<wchar_t> >::_S_pback_size ()
#14 0xbffff454 in ?? ()
#15 0x08087a6e in ?? ()
#0 0xb7cc53ae in waitpid () from /lib/tls/libc.so.6

Incidentally, it still crashes when you set LD_ASSUME_KERNEL to 2.4.something.

[zx64]

Just had a look at the other thread and setting ScreenWindowed=1 in the preferences makes it no longer segfault on startup (I had to create the file manually), but now fails with "Couldn't open language file language/(null).txt".

Further system info:
$ uname -a
Linux andalusite 2.6.11-1-686 #1 Fri May 20 07:34:54 UTC 2005 i686 GNU/Linux
Output from lspci for the graphics card:
0000:01:00.0 VGA compatible controller: ATI Technologies Inc Radeon Mobility M6 LY
0000:00:01.0 0604: 8086:3576 (rev 02)

This is Debian's XFree86 4.3 (i.e. heavily patched), and OpenGL works for other applications.

Hope this helps,

Euan.

[John]

Try adding the line

TextLanguage = english

to the preferences.txt

[zx64]

Setting that now causes it to a) truncate preferences.txt and b) crash at:

(still demo version 1.2.1)

retAddress = 0x808ff15
retAddress = (nil)
(with the preferences section of blackbox.txt empty....)

If I remove permissions to write from preferences.txt it now complains about this:
Failed to open audio output device: "Fragment size must be a power of two".

Can I recomend you audit your startup code for the various things that are ignoring error codes from functions?

For example, the fullscreen related crash is probably because SDL_SetVideoMode returns NULL if it fails.

The language = (null) problem is probably because you don't handle openning and reading from preferences.txt failing gracefully (and indeed don't appear to generate a default preferences.txt file with at least TextLanguage=english).

Truncating the prefs file is probably caused by you openning the file for writing but not writing/flushing settings back to disk, although I'm confused as to what it is doing because it reads the prefs fine if it can't write to the file, but doesn't read them if it can write.

Hope this helps,

Euan.

[zx64]

retAddress = 0x808ff15
retAddress = (nil)
(with the preferences section of blackbox.txt empty....)

(...)

Truncating the prefs file is probably caused by you openning the file for writing but not writing/flushing settings back to disk, although I'm confused as to what it is doing because it reads the prefs fine if it can't write to the file, but doesn't read them if it can write.

Quick bit of strace'ing shows the prefs are being read, but the file is read again later to generate the blackbox.txt file, by which time the file has been truncated (except when it doesn't truncate the file because it doesn't have permission).

One other thing spotted when running strace was this:
open("/tmp/darwinia.gdb", O_WRONLY|O_CREAT|O_TRUNC, 0666)
this is vulnerable to a symlink attack. Same again for darwinia.stacktrace, as you don't appear to check if unlink succeeds (because the files are owned by another user).

Euan.

[zx64]

One other thing spotted when running strace was this:
open("/tmp/darwinia.gdb", O_WRONLY|O_CREAT|O_TRUNC, 0666)
this is vulnerable to a symlink attack. Same again for darwinia.stacktrace, as you don't appear to check if unlink succeeds (because the files are owned by another user).

Furthermore, there's a race condition between unlink() and open() (because the filename is fixed), so one should use tmpfile() instead (I am unsure of what win32 provides for secure temporary file creation).

I know that this sort of problem is rather academic given that systems on which Darwinia would be run are almost certainly single user or limited to trusted users, but it is something fairly easy to do.

Euan

[NeoThermic]

One other thing spotted when running strace was this:
open("/tmp/darwinia.gdb", O_WRONLY|O_CREAT|O_TRUNC, 0666)
this is vulnerable to a symlink attack. Same again for darwinia.stacktrace, as you don't appear to check if unlink succeeds (because the files are owned by another user).

Furthermore, there's a race condition between unlink() and open() (because the filename is fixed), so one should use tmpfile() instead (I am unsure of what win32 provides for secure temporary file creation).

I know that this sort of problem is rather academic given that systems on which Darwinia would be run are almost certainly single user or limited to trusted users, but it is something fairly easy to do.

Euan

For the slightly less knowledgeable, can you explain what a symlink attack is and how its dangerous?

NeoThermic

[zx64]

For the slightly less knowledgeable, can you explain what a symlink attack is and how its dangerous?
NeoThermic

Sure. One user creates a symbolic link called e.g. /tmp/darwinia.gdb and points it somewhere (e.g. at a file in another user's home directory), then when the target user runs the program and it generates a blackbox file, the targetted file gets overwritten. The severity of the problem depends on whether the attacker can also control what gets written (e.g. replace your .bash_profile with a script to copy your private keys to /tmp as world readable).

The race condition I mention is between one process unlinking (removing) the file then opening the file and another process recreating the symlink after it has been unlinked but before it has been opened.

Avoiding the problem is achieved by having a (pseudo)randomly generated filename, thus reducing the probability of the attacker successfully guessing what to call the symlink, or not using temporary files (I suspect you could replace this stuff with some pipes and gdb parameters).

As mentioned before, the problem is fairly academic but has the potential to be rather annoying.

Euan.

[John]

All good points. Will try to come up with a better fix as soon as Chris' broadband is activated. In the meantime, try a preference file something like this:

Code: Select all

ServerAddress = 127.0.0.1
BypassNetwork = 1
IAmAServer = 1
TextLanguage = english
TextSpeed = 15
HelpEnabled = 0
SoundLibrary = software
SoundMixFreq = 22050
SoundMasterVolume = 255
SoundChannels = 16
SoundHW3D = 0
SoundSwapStereo = 1
SoundMemoryUsage = 1
SoundBufferSize = 512
SoundDSP = 0
ScreenWidth = 1024
ScreenHeight = 768
ScreenWindowed = 1
ScreenZDepth = 24
ScreenColourDepth = 32
ScreenRefresh = 60
RenderLandscapeDetail = 1
RenderWaterDetail = 2
RenderBuildingDetail = 2
RenderEntityDetail = 2
RenderCloudDetail = 2
RenderPixelShader = 0
ControlUp = key E
ControlDown = key Q
ControlLeft = key A
ControlBackwards = key S
ControlRight = key D
ControlForwards = key W
ControlChatLog = key TAB
ControlZoom = key Z
ControlDeselect = key SPACE
ControlMouseButtons = 3
RenderLandscapeMode = 2
ModSystemEnabled = 1
ManuallyScaleTextures = 0
BootLoader = random
UserProfile = NewUser


You might need to change the graphics settings (colour / z depth) in order to get it to work. The problem is that if Darwinia cannot set the initial desired mode, it will want to display a dialog box telling you it has reverted to a fallback mode. However, this requires the language module which hasn't been initialised at this stage.

With respect to the default preferences, it appears that they are only set if the preferences.txt file does not exist at all. This is normally fine, except due to this bug mentioned above. Hopefully we'll get it sorted soon.

Out of curiousity, what colour depth are you running at? What graphics card and drivers are you using?

Another thing to try is to download a demo beta and see if that helps at all (best try with and without any preferences.txt in ~/.darwinia/demo).

[zx64]

All good points. Will try to come up with a better fix as soon as Chris' broadband is activated. In the meantime, try a preference file something like this:

Thanks!

Out of curiousity, what colour depth are you running at? What graphics card and drivers are you using?

It's a Radeon Mobility M6 using the OSS drivers in 16 bit colour, which might be a problem as it is a fairly low spec card (although it can run quake3 fairly well if you tweak the settings).
(I'll also have an nVidia 6600GT to play with on my desktop soonish)

Another thing to try is to download a demo beta and see if that helps at all (best try with and without any preferences.txt in ~/.darwinia/demo).

I'll give that a try in a bit.

Euan.

[zx64]

Hmm, the beta worked without any need for tweaking.

It was getting about 10FPS on the openning scene in 640x480 fullscreen with all the detail turned down.

*Edit* Having played the tutorial for a bit, it's playable (gots to 18FPS when I checked at one point) although not as pretty as it could be, and I occasionally get it complaining about client lagging behind server.

[John]

You might get a better framerate by disabling the pixel effect (graphics preferences window), as this is particularly slow with the OSS ati radeon drivers. Also running at 24bit or 32bit colour depth might improve things.

[zx64]

You might get a better framerate by disabling the pixel effect (graphics preferences window), as this is particularly slow with the OSS ati radeon drivers. Also running at 24bit or 32bit colour depth might improve things.

Yeah, I'd already disabled the pixel effect. Are there plans to autodetect graphical settings (as it was fairly painful to navigate the UI until I turned everything down)?

Incidentally, is the corresponding 1.2.1b beta installer for the full game available?

Thanks,

Euan.