crash at startup

[droebbel77]

ctp2 always crashes at startup after changing screen resolution, but before playing any video. I also deactivated the intro, ctp2 still crashed.
This happens on W2k-sp4, both on a "real" system and inside Virtualbox.
The only common part of these systems seems to be the cpu (as it is virtualised using pacifica), a Athlon 64 X2 4600 EE.
I tried vanilla ctp, but I also updated to playtest to get a proper crash report. Here it is:

Version 2007-05-19
0x00789ac8 [?HandleKeyboardEvents@aui_UI@@QAE?AW4AUI_ERRCODE@@ XZ + 0x19]
0x0078a2f0 [?Process@aui_UI@@UAE?AW4AUI_ERRCODE@@XZ + 0x2b]
0x0040f93b [?ProcessUI@CivApp@@AAEHIAAI@Z + 0x234]
0x0040fc8e [?Process@CivApp@@QAEHXZ + 0xa7]
0x00408e26 [?CivMain@@YGHPAUHINSTANCE__@@0PADH@Z + 0x3ea]
0x0040879f [WinMain@16 + 0x6d]
0x009f8d6c [WinMainCRTStartup + 0x134]
0x77e77903 [__onexitbegin + 0x772aabab]

Any ideas what might cause the crash?

[Ekmek]

this looks like its with the AE build. did you add the 09.09.2006 playtest than the latest playtest build 771b? the links are in my signature.

[droebbel77]

with 771b:

Version 2007-07-24
0x0078df08 [?HandleKeyboardEvents@aui_UI@@QAE?AW4AUI_ERRCODE@@ XZ + 0x19]
0x0078e730 [?Process@aui_UI@@UAE?AW4AUI_ERRCODE@@XZ + 0x2b]
0x0040f94b [?ProcessUI@CivApp@@AAEHIAAI@Z + 0x234]
0x0040fc9e [?Process@CivApp@@QAEHXZ + 0xa7]
0x00408e36 [?CivMain@@YGHPAUHINSTANCE__@@0PADH@Z + 0x3ea]
0x004087af [WinMain@16 + 0x6d]
0x009fcdcc [WinMainCRTStartup + 0x134]
0x77e787f5 [__onexitbegin + 0x772a687d]

[Ekmek]

it looks like an interface issue. did you copy all of the files over? the only other option would be a clean re-install (sorry)

[droebbel77]

Funnily enough, this is what I already did. Both systems were clean installs on top of newly installed w2k. There weren't too many things in common there: the w2k disk (couldn't check), the ctp disk (works on other system) and the cpu.
I might try to check with another windows disk, if I can manage to get one.
If only the linux version was fully functional, but it starts at least...

[Ekmek]

thx, i guess there is a problem with w2k that we haven't known about.

[droebbel77]

Nope.
Just checked with XP: same crash. Tested various "compatibility settings" with no effect.
But: I had used another virtual machine for testing, with VirtualBox. Now I converted the disk image to another format and started it with qemu. I was surprised to see XP actually boot, it just installed some drivers. And there, ctp finally started.

Now this is what we have:
- 2k does not work on real hardware and in VBox.
- XP does not work in VBox, but the very same installation works in qemu.

Now what does the real system have in common with VBox that qemu does not have? AFAIK the only thing is the CPU, as this is virtualised using pacifica in VBox while emulated in qemu.

I wanted to doublecheck with kvm (which is essentially qemu with hardware virtualisation), but as it is quiet new and alpha, I could not get XP to boot.

Now what do you think? I'll be glad to run more tests, just tell me what information you need.

Ah yes, I nearly forgot: time to give exact information about the cpu.
This is what linux says (I do not know how to find such extensive information in Windows):

processor : 0
vendor_id : AuthenticAMD
cpu family : 15
model : 75
model name : AMD Athlon(tm) 64 X2 Dual Core Processor 4600+
stepping : 2
cpu MHz : 1000.000
cache size : 512 KB
physical id : 0
siblings : 2
core id : 0
cpu cores : 2
fdiv_bug : no
hlt_bug : no
f00f_bug : no
coma_bug : no
fpu : yes
fpu_exception : yes
cpuid level : 1
wp : yes
flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 ht syscall nx mmxext fxsr_opt lm 3dnowext 3dnow pni cx16 lahf_lm cmp_legacy svm cr8legacy ts fid vid ttp tm stc
bogomips : 2010.49
clflush size : 64

processor : 1
vendor_id : AuthenticAMD
cpu family : 15
model : 75
model name : AMD Athlon(tm) 64 X2 Dual Core Processor 4600+
stepping : 2
cpu MHz : 1000.000
cache size : 512 KB
physical id : 0
siblings : 2
core id : 1
cpu cores : 2
fdiv_bug : no
hlt_bug : no
f00f_bug : no
coma_bug : no
fpu : yes
fpu_exception : yes
cpuid level : 1
wp : yes
flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 ht syscall nx mmxext fxsr_opt lm 3dnowext 3dnow pni cx16 lahf_lm cmp_legacy svm cr8legacy ts fid vid ttp tm stc
bogomips : 2010.49
clflush size : 64

P.S.
I just made another check: I started the "physical" w2k installation (where ctp didn't start) inside vmware server , where you can use real partitions als virtual disks - same software, different hardware, some extra drivers. Ctp2 worked.

[Fromafar]

Looking at the crash text, it clearly is a program error. I don't think it is OS specific. It could be be the speed of the processor or the dual core, causing the Process loop to be started before the initialisation has been completed.

Without changing the code, you could try something like runfirst to force the program to use just 1 processor.

[droebbel77]

I forgot to mention that I had already tried RunOnCPU. Now I tried RunFirst too. I also set the system to maximum powersave (hoping to set CPU frequency to minimum by that, but how do I check?) with no effect. I'll check that in VBox with the cpu pinned to minimum in the host system when I'm back from holiday in about two or three weeks.
Please note however that a programming error as you described has no effect on linux for me.
Something else I noticed: ctp needs about 10 seconds until it finally crashes, during which time it does virtually nothing. Windows seems frozen, only ctrl-alt-del works to call the task manager. I cannot change to any other task, and I wonder what might prevent windows from acting like the preemptive multitasking system it claims to be.
As it works on linux, the error might have something to do with graphics and maybe directX? What else is different?

[Fromafar]

The timing, if my guess (Process loop started before the initialisation has been completed) is correct. But it could also be a failing - keyboard handler - initialisation. Difficult to say, without running a debug version at your machine.

Maybe E or Martin can try to merge the attached aui_ui.h/cpp files in the trunk for a next release. I have added some initialisation and tests that could prevent the reported crash from occurring.

Don't know about the slow crash, but running through a virtual machine will usually not speed up matters. When the program crashes, it has to generate the crash text (and maybe other files - do you have more logging enabled?) and has to release lots of resources.