Tears of St. Lucia segfaults on Linux

[KCat]

I'm trying to run the mod, but I'm running into several issues. First is when the game loads, it immediately bombs with

dlopen '/home/kitty/.doom3/saintlucia/gamex86.so' failed: libboost_filesystem-gcc41-1_34_1.so.1.34.1: cannot open shared object file: No such file or directory

Looking on my system, it seems I have /usr/lib/libboost_filesystem.so (and /usr/lib/libboost_filesystem-mt.so). If I add a symlink, the game will start. I can then run 'dmap saintlucia' (though the wiki says to do thiefs_den, which doesn't work). After a few minutes, I can then start a new game, purchase some gear and watch the opening cinematic. But as the "progress bar" fills up, the game crashes, with the last lines being:

----- idRenderModelManagerLocal::EndLevelLoad -----
0 models purged from previous level,   877 models kept.
---------------------------------------------------
----- idImageManager::EndLevelLoad -----
WARNING: Couldn't load image: _emptyname
WARNING: Couldn't load image: -
WARNING: Couldn't load image: extinguishable/hanging_lantern
WARNING: Couldn't load image: extinguishable/streetlamps/roundstreetlamp
WARNING: Couldn't load image: hair
0 purged from previous
 211 kept from previous
1306 new loaded
all images loaded in 136.5 seconds
----------------------------------------
----- idSoundCache::EndLevelLoad -----
24573k referenced
5963k purged
----------------------------------------
sound: missing efxs/saintlucia.efx
signal caught: Segmentation fault
si_code 1
Trying to exit gracefully..
--------- Game Map Shutdown ----------
--------------------------------------
Shutting down sound hardware
------ OSS Sound Shutdown ------
close sound device
--------------------------------
idRenderSystem::Shutdown()
------------ Game Shutdown -----------
--------- Game Map Shutdown ----------
--------------------------------------
Shutdown event system
--------------------------------------
shutdown terminal support

I'm using 32-bit Gentoo, with a properly patched Doom3. The previous demo map worked fine. Any help would be greatly appreciated.

[greebo]

Hm. You shouldn't need to dmap saintlucia (the map is precompiled), but doing so shouldn't hurt either. It will create the .proc/.cm/.aas32/.aas_rat files outside of the PK4 though, which can cause confusion later.

 

Have you tried starting the map without dmapping first? I sometimes get a memory allocation failure when dmapping and starting the map in the same session.

[KCat]

Hm. You shouldn't need to dmap saintlucia (the map is precompiled), but doing so shouldn't hurt either. It will create the .proc/.cm/.aas32/.aas_rat files outside of the PK4 though, which can cause confusion later.

 

Have you tried starting the map without dmapping first? I sometimes get a memory allocation failure when dmapping and starting the map in the same session.

The crash would happen even after I tried starting it again. The wiki says the Linux version needs to run the dmap command, however, I just did fresh extraction (deleted the old .doom3/saintlucia and re-extracted the executable) and tried to start a game without running dmap. Now it gets out-of-memory killed when it finishes loading. I have 1GB RAM + 512MB swap, and 256MB VRAM, which should be enough from what I read.

[greebo]

Ah, I copied the article basically from thiefs_den and forgot to remove that part about dmap. It should not be necessary.

 

Hm. Out of memory definitely sounds like the 512 MB swap might no be enough?

[Ishtvan]

sound: missing efxs/saintlucia.efx

signal caught: Segmentation fault

si_code 1

Trying to exit gracefully..

The EFX file is for setting up EAX sound and should be optional, AFAIK we didn't include one. What is your sound setup like?

[greebo]

I don't think that the missing EFX file is causing the segfault, it just happens to be the line before the actual segfault message is written.

[OrbWeaver]

Are you sure your Boost is the right version? If you have to add a manual symlink it may be that the compiler version does not match; Boost is a C++ library and is very sensitive to this sort of thing.

 

(I guess looking at static-linking Boost on Linux should be a matter of priority, if this is the cause of the issue then it is going to affect a lot of people in theory).

[KCat]

Hm. Out of memory definitely sounds like the 512 MB swap might no be enough?

I dunno, swap should really be considered as an 'out of memory protection', IMO. It's there in case you use too much memory, but should not be required (I know in particular, Linux users sometimes like to disable swap). The wiki says I need at least 512MB RAM, with 1GB recommended. I have 1GB+512MB, so I don't see why I'd be running out of memory.

 

Is it possible the texture resolution is just too high by default, causing the video drivers to allocate a bunch of memory on its own? I don't see an option to lower the texture resolution, and I'm not sure which cvars control that.

 

Are you sure your Boost is the right version? If you have to add a manual symlink it may be that the compiler version does not match

I have Boost 1.34.1-r2, and GCC 4.1.2. The Linux C++ ABI has been pretty stable since about GCC 3.4, AFAIK, so it'd be odd for a lib to have not only the package version (instead of the library ABI version), but also the GCC version "encoded" on the filename.

Edited October 22, 2008 by KCat

[Tels]

Are you sure your Boost is the right version? If you have to add a manual symlink it may be that the compiler version does not match; Boost is a C++ library and is very sensitive to this sort of thing.

 

(I guess looking at static-linking Boost on Linux should be a matter of priority, if this is the cause of the issue then it is going to affect a lot of people in theory).

 

It also effects people in practice because I had the same issue today on a 64bit Ubuntu, you first need to hunt down the 32bit libboost library, and hope they still have proper matching one for your compiler. Thats quite tricky and might easily throw off unexperienced linux users (and we get more of these each day Even for users like me it is annoying.

[Tels]

I dunno, swap should really be considered as an 'out of memory protection', IMO. It's there in case you use too much memory, but should not be required (I know in particular, Linux users sometimes like to disable swap). The wiki says I need at least 512MB RAM, with 1GB recommended. I have 1GB+512MB, so I don't see why I'd be running out of memory.

 

Technically, 1Gbyte + 512Mbyte should be enough. But it might not be enough (depending on what else uses memory in your system, like KDE, Xserver etc), I am pretty sure we didn't measure the actual memory consumption, tho. I am gonna do this now and post later what it really uses.

 

Is it possible the texture resolution is just too high by default, causing the video drivers to allocate a bunch of memory on its own? I don't see an option to lower the texture resolution, and I'm not sure which cvars control that.

 

Shouldn't make much difference as the textures should all fit into 256Mbyte (otherwise your card would swap a lot to main memory), but then, I am not sure if there aren't multiple copies of them in main memory, video memory etc.

 

The cvars for downscaling textures are something with downsampling - look them up, in DoomConfig.cfg and try to change them.

[KCat]

Technically, 1Gbyte + 512Mbyte should be enough. But it might not be enough (depending on what else uses memory in your system, like KDE, Xserver etc), I am pretty sure we didn't measure the actual memory consumption, tho. I am gonna do this now and post later what it really uses.

Shouldn't make much difference as the textures should all fit into 256Mbyte (otherwise your card would swap a lot to main memory), but then, I am not sure if there aren't multiple copies of them in main memory, video memory etc.

I know GL drivers will typically store memory copies of static resources (eg. textures) in case the video memory gets clobbered and it has to reload them (or if it has to purge them from VRAM for other resources). Most apps I see also tend to hold their own copy of images as well, in case they need to read from, or change, them.

 

The cvars for downscaling textures are something with downsampling - look them up, in DoomConfig.cfg and try to change them.

Well, I changed image_preload to 0 (it was 1) and image_useNormalCompression to 1 (it was 0), and it starts up now.. though it took quite a while for the level to load, and performance wasn't all that great. I have an AMD Athlon X2 4200+ with a Geforce 8600GT, and no desktop compositing. I can try turning on the various image_downSize* options to see if that helps any more.

[free_cogg]

Same problem for me on 64bit Gentoo. Thief's Den works fine but St.Lucia is depending on a very specific Boost library.

 

 ~/.doom3 $ ldd ./saintlucia/gamex86.so 
ldd: warning: you do not have execution permission for `./saintlucia/gamex86.so'
       linux-gate.so.1 =>  (0xf7fc4000)
       libIL.so.1 => /usr/lib32/libIL.so.1 (0xf7486000)
       libboost_filesystem-gcc41-1_34_1.so.1.34.1 => not found
       libstdc++.so.6 => /usr/lib/gcc/x86_64-pc-linux-gnu/4.1.2/32/libstdc++.so.6 (0xf739f000)
       libm.so.6 => /lib32/libm.so.6 (0xf7378000)
       libgcc_s.so.1 => /lib32/libgcc_s.so.1 (0xf736c000)
       libc.so.6 => /lib32/libc.so.6 (0xf723c000)
       libpng12.so.0 => /usr/lib32/libpng12.so.0 (0xf7218000)
       libjpeg.so.62 => /usr/lib32/libjpeg.so.62 (0xf71f8000)
       libtiff.so.3 => /usr/lib32/libtiff.so.3 (0xf71a3000)
       /lib/ld-linux.so.2 (0xf7fc5000)
       libz.so.1 => /lib32/libz.so.1 (0xf718f000)

(I guess looking at static-linking Boost on Linux should be a matter of priority, if this is the cause of the issue then it is going to affect a lot of people in theory).

 

It would make life a whole lot easier.

[cha0t1c]

Same problem for me on 64bit Gentoo. Thief's Den works fine but St.Lucia is depending on a very specific Boost library.

 

 ~/.doom3 $ ldd ./saintlucia/gamex86.so 
ldd: warning: you do not have execution permission for `./saintlucia/gamex86.so'
       linux-gate.so.1 =>  (0xf7fc4000)
       libIL.so.1 => /usr/lib32/libIL.so.1 (0xf7486000)
       libboost_filesystem-gcc41-1_34_1.so.1.34.1 => not found
       libstdc++.so.6 => /usr/lib/gcc/x86_64-pc-linux-gnu/4.1.2/32/libstdc++.so.6 (0xf739f000)
       libm.so.6 => /lib32/libm.so.6 (0xf7378000)
       libgcc_s.so.1 => /lib32/libgcc_s.so.1 (0xf736c000)
       libc.so.6 => /lib32/libc.so.6 (0xf723c000)
       libpng12.so.0 => /usr/lib32/libpng12.so.0 (0xf7218000)
       libjpeg.so.62 => /usr/lib32/libjpeg.so.62 (0xf71f8000)
       libtiff.so.3 => /usr/lib32/libtiff.so.3 (0xf71a3000)
       /lib/ld-linux.so.2 (0xf7fc5000)
       libz.so.1 => /lib32/libz.so.1 (0xf718f000)

 

 

It would make life a whole lot easier.

 

 

I am having the same issue with libboost_filesystem.so.1.36.0. Tried a syslink but it seems that this particular build is looking specifically for so.1.34.0. I agree with the above post in that static seems the way to go. Thief's Den and Doom3 run exceptionally well. As an aside, great work folks!!! Looking forward to the finished product!

[greebo]

Incidentally, I've been working on that linking problem yesterday, and boost-filesystem is now statically linked in. Expect this problem to be gone in the release.