Civilization game crashes at start up

[Asmo]

I am running Haiku on a VMWare (main OS is Mac OS X ). The game was installed on a secondary hard drive, without any errors, but when I run it, it crashes.

I've downloaded the last VMWare image from the haiku-os.org website, date : 7th of June 2008.

Please check the following log to see what I get when I click on the Debug button :

GNU gdb 6.3
Copyright 2004 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show warranty" for details.
This GDB was configured as "i586-pc-haiku"...(no debugging symbols found)

[tcsetpgrp failed in terminal_inferior: Invalid Argument]
Thread 176 caused an exception: Divide error
Reading symbols from /boot/beos/system/lib/libbe.so...(no debugging symbols found)...done.
Loaded symbols for /boot/beos/system/lib/libbe.so
Reading symbols from /boot/beos/system/lib/libmedia.so...(no debugging symbols found)...done.
Loaded symbols for /boot/beos/system/lib/libmedia.so
Reading symbols from /boot/beos/system/lib/libgame.so...
(no debugging symbols found)...done.
Loaded symbols for /boot/beos/system/lib/libgame.so
Reading symbols from /boot/beos/system/lib/libnetwork.so...(no debugging symbols found)...done.
Loaded symbols for /boot/beos/system/lib/libnetwork.so
Reading symbols from /boot/beos/system/lib/libroot.so...done.
Loaded symbols for /boot/beos/system/lib/libroot.so
Reading symbols from /boot/beos/system/lib/libpng.so...done.
Loaded symbols for /boot/beos/system/lib/libpng.so
Reading symbols from /boot/beos/system/lib/libz.so...done.
Loaded symbols for /boot/beos/system/lib/libz.so
Reading symbols from /boot/beos/system/lib/libstdc++.r4.so...done.
Loaded symbols for /boot/beos/system/lib/libstdc++.r4.so
[tcsetpgrp failed in terminal_inferior: Invalid Argument]

[Switching to team /Haiku1/home/apps/CivCTP/ctp_program/ctp/CivCTP (176) threadCivCTP (176)]
0x00e05c10 in BList::Resize () from /boot/beos/system/lib/libbe.so
(gdb)

[anevilyak]

Since I'm planning on making some changes to BList anyways, I'll look into this one.

[anevilyak]

Could you try again with hrev25920 please? I'm not seeing this crash here, though I am seeing problems with how it's using BDirectWindow (that may just be my graphics driver though).

[Asmo]

Hi anevilyak,

I will try with the last VMWare image ( from the 10th ) and see if it still crashes. Thanks.

[Asmo]

Found out that the 10th of June VMWare is actually hrev25910, I will wait until the VMWare image of hrev25920 is out to test it.

[Asmo]

The app runs without any message but it just hangs taking 100% of CPU.

​http://img152.imageshack.us/img152/668/image1dp2.png

[anevilyak]

That seems to be a different problem...over here it tried and failed to resolution switch, which resulted in it not working correctly for me either. What graphics chipset are you using?

[Asmo]

It's a GMA 950.

[bonefish]

Tested with hrev26126: I run into the same problem as Asmo: 100% CPU usage. It's an endless loop in BList::_ResizeArray(). The BList implementation is not to blame though -- the list in question is a global list and is used before it is constructed.

After working around by setting fBlockSize to some usable value, if it is 0, the application crashes. It fails to fopen() one of its program files and doesn't check the return value. The PackageInstaller apparently failed to install those (though it actually reported more files to install than SoftwareValet in BeOS) -- they seem to be part of the language options. Installing via SoftwareValet in Haiku doesn't work -- it only installs the directory and a symlink and reports the installation completed.

Manually copying the directory from the BeOS installation at least gets the application going (its window seems to be located incorrectly, though). It segfaults when starting the game, though. When ignoring the debugger window one can actually play a bit.

[anevilyak]

Interesting, I didn't see that behavior, but BDirectWindow seemed completely broken on my graphics driver so it didn't really do much here besides resize the screen and present a garbled display. How is it possible to use a global list before constructing it? I thought all globals were initialized by the runtime before main() was called?

[bonefish]

Replying to anevilyak:

How is it possible to use a global list before constructing it? I thought all globals were initialized by the runtime before main() was called?

They are, but the use of the BList also happens in a global constructor, which is called earlier. The author(s) apparently relied on them being called in a different order. If they thought about that anyway -- they also create threads, which is usually nothing one does in a global constructor (that's the problem in this case BTW, since the BList is apparently used for some kind of thread objects).

[anevilyak]

So, what's the verdict on this one? Is this solveable or.. ?

[bonefish]

Replying to anevilyak:

So, what's the verdict on this one? Is this solveable or.. ?

I liked the game, but it apparently is buggy software and we shouldn't bend over backwards to make it work.