4548 – STANDALONE on Windows requires baseq3 or else it doesn't let the game start

Bug 4548 - STANDALONE on Windows requires baseq3 or else it doesn't let the game start

Status:	RESOLVED WORKSFORME

Alias:	None

Product:	ioquake3
Classification:	Unclassified
Component:	Platform
Version:	GIT MASTER
Hardware:	PC Windows Vista

Importance:	P3 critical
Assignee:	Zachary J. Slater
QA Contact:	ioquake3 bugzilla mailing list

URL:

Depends on:
Blocks:

Reported:	2010-02-16 09:24 EST by tinkah
Modified:	2010-02-17 15:21:52 EST
CC List:	2 users (show)

See Also:

Description tinkah 2010-02-16 09:24:48 EST

[16:03:37]	<fs-a>	What does one have to change for the game not to freeze on loading screen if it's build with STANDALONE?
[16:04:44]	-->|	a-v (~and@unaffiliated/a-v) has joined #ioquake3
[16:08:13]	<Tequila>	fs-a: how do you start the game ?
[16:09:39]	<fs-a>	It's same command line or not, +devmap or not.
[16:10:01]	<fs-a>	I think it happened with last update.
[16:10:04]	<Tequila>	have you build the engine against r1774 ?
[16:10:10]	<fs-a>	yes
[16:10:19]	<Tequila>	there was an update this morning
[16:10:22]	<fs-a>	well, that only had a Makefile change.
[16:10:28]	<fs-a>	to add a mingw lib
[16:10:42]	<Tequila>	did you clean your build before rebuild ?
[16:10:46]	<fs-a>	the behavior persists.
[16:10:56]	<fs-a>	yes and it's the same both from mingw and msvc
[16:11:12]	<fs-a>	it goes away if it's not STANDALONE
[16:11:20]	<Tequila>	changes on Makefile won't apply between rev if you don't run "make clean"
[16:11:37]	<fs-a>	make, i made clean and distclean
[16:11:48]	<fs-a>	it's same on msvc
[16:12:08]	<Tequila>	I tested cross-compilation with linux, it works
[16:12:25]	<fs-a>	IIRC that behavior was there before if it was STANDALONE and "baseq3" was left without changing to the mod.
[16:12:37]	<fs-a>	now it's like that doesn't affect
[16:12:39]	<fs-a>	it
[16:13:00]	<fs-a>	When it happened with "baseq3" and STANDALONE I didn't care because it went away when using a mod
[16:13:08]	<fs-a>	but now it happens with everything
[16:13:47]	<fs-a>	I can only start it propely with baseq3 (vanilla svn) and no STANDALONE
[16:14:18]	<fs-a>	it may be something in sys_win32
[16:15:20]	<fs-a>	..which was there before but now was aggravated.
[16:18:21]	<fs-a>	is there any developer on windows?

Comment 1 Monk 2010-02-16 15:25:25 EST

Perhaps related to http://bugzilla.icculus.org/show_bug.cgi?id=4505

Comment 2 tinkah 2010-02-16 17:27:55 EST

No, pretty sure it's related to 1773/1774.

It doesn't go in spamming the stderr and it doesn't go away with those UI calls edits.

*I have a git repository that works once I revert those edits.*

In fact, I tried a fresh repository of 1772 and it went fine, once I updated it to 1774, not fine.


I suspect it's something in that lengthy win32 code added since I heard it doesn't occur on linux.

Comment 3 tinkah 2010-02-16 17:31:29 EST

I did try to find a way to directly debug it but I can't find a way to interrupt gdb(ctrl-c) on Windows 7 64 (related binaries here are all 32bit) on a couple of versions I tried, but on msys and on common cmd, even the gdb guys said it 'should' work if it's a relatively recent mingw; well it doesn't.

Comment 4 tinkah 2010-02-16 19:43:54 EST

ok i managed to see some debugging on MS C; 

it definitely goes to 

Cvar_SetCheatState() [particularly for(var = cvar_vars; var ; var = var->next)] at points and returns to it

it goes to SDL_Delay() and periodically returns to it

at several points it drops to (dis)assembly code such as

774500E7  nop  
774500E8  mov         eax,58h  
774500ED  mov         ecx,1Dh  
774500F2  lea         edx,[esp+4]  
774500F6  call        dword ptr fs:[0C0h]  
774500FD  add         esp,4  
77450100  ret         14h  
77450103  nop  
77450104  mov         eax,59h  
77450109  xor         ecx,ecx  
7745010B  lea         edx,[esp+4]  
7745010F  call        dword ptr fs:[0C0h]

(perhaps compiled vm, dunno though)

That Sleep of SDL_Delay() sounds very suspicious. it stops there a lot. (I have debugging symbols of SDL on MS C, it's called on the library).



Commenting out SDL_Delay on SDL libs completely freezes the SYSTEM on (ok almost) run, took some seconds to stop debugging and recover.

apparently that sleep was preventing that behavior for certain occasions.


and again around 'for(var = cvar_vars; var ; var = var->next)' of Cvar_SetCheatState()  and looping through those.



any ideas based on that information?

Comment 5 tinkah 2010-02-17 12:25:25 EST

please close this for the following reasons:

I managed to make it run after a clean tree.

and b) even if it was remotely related to what Monk is describing it is quite vague and not ultimately related.


sorry for this.

Comment 6 Tim Angus 2010-02-17 15:21:52 EST

Top of page