ProQuake bug?

[Zop]

I downloaded the source from ProQuake 4: The official continuation of ProQuake and eventually got it to compile (damn MS changing stuff in Visual Studio), but I found it crashed with a weird bug: "COM_LoadFile: bad usehunk".

I found that the variable usehunk was 10 when it crashed, which is basically impossible (due to a lengthy explanation), but I did end up finding the problem.

COM_FileBase() (in common.c) was crashing on "quake.rc" since there was no slash character in the string. (I guess no one else has a quake.rc file?)

The solution was to change

for (s2 = s ; *s2 != '/' ; s2--);

to

for (s2 = s ; *s2 > in && *s2 != '/' ; s2--);

[R00k]

/*
============
COM_FileBase
============
*/
void COM_FileBase (char *in, char *out)
{
	char	*s, *s2;
	
	s = in + strlen(in) - 1;
	
	while (s != in && *s != '.')
		s--;
	
	for (s2 = s; s2 != in && *s2 && *s2 != '/'; s2--)//MH
		;
	
	if (s-s2 < 2)
		strcpy (out, "?model?");
	else
	{
		s--;
		strncpy (out, s2+1, s-s2);
		out[s-s2] = 0;
	}
}

MH fixed this awhile back. must be a modern compiler thing.

[Zop]

Strange. Perhaps the PQ source hosted here is a bit old?

[Izhido]

Apologies for resurrectibg this old thread, I just wanted to clear things up a bit. Hope it helps future modders.

I can confirm this is a *very* old vanilla bug. Right now, I'm working on a iOS vanilla port (more details on that in a future thread); by turning on Xcode's Address Sanitizer tool, I've stumbled upon that bug. The COM_FileBase function seems to assume any path strings are preceded by a null character, and so in exploring the path to find the file name it checks only for the presence of either a slash or \0 to stop the search. This is wrong, of course. I fixed it in my code by also checking that the current pointer is not beyond the beginning of the string, and to take corrective actions if that is detected.

Oddly enough, that fix also unexpectedly corrected something else in my port: The player weapon is now visible; it wasn't before the correction. Go figure.

[Zop]

Two bugs killed for the price of one? Good deal.

[Izhido]

Update on the last bug I mentioned: it had nothing to do with COM_FileBase, but with the Address Sanitizer itself. Long story short, a global variable (envmap) was not properly initialized, so the weapon model had little to no chance of being displayed at any given session.