Old sources crash when compiled in fully updated win 7

Discuss programming topics for any language, any source base. If it is programming related but doesn't fit in one of the below categories, it goes here.
Post Reply
revelator
Posts: 2621
Joined: Thu Jan 24, 2008 12:04 pm
Location: inside tha debugger

Old sources crash when compiled in fully updated win 7

Post by revelator »

Ran into a rather strange problem it would seem.
Tried to do some work on my realm engine, and it crashed outright after i built it, so i thought maybe some of the changes i did was at fault but even after reverting it still crashes.
So i tried to build tomazquake 148 from an unmodified source, and it also crashes Oo in fact all older quake engines crash outright, and so far the only ones i could get running where quakespasm darkplaces and FTE.
Seems the older sources have some nasties that no longer fly though im a bit baffled as to which windows update changed things this much.
Productivity is a state of mind.
Vic
Posts: 21
Joined: Sun Nov 07, 2010 12:42 am

Re: Old sources crash when compiled in fully updated win 7

Post by Vic »

Yeah, vanilla glquake is known to crash with newer drivers due to GL strings overflowing the string buffer and the range checks missing..
revelator
Posts: 2621
Joined: Thu Jan 24, 2008 12:04 pm
Location: inside tha debugger

Re: Old sources crash when compiled in fully updated win 7

Post by revelator »

Ah beat me dead and string me up :shock: Just goes to tell how long i have been away cause i actually used to know this :lol:
Guess getting upto speed again will take some time.
Productivity is a state of mind.
revelator
Posts: 2621
Joined: Thu Jan 24, 2008 12:04 pm
Location: inside tha debugger

Re: Old sources crash when compiled in fully updated win 7

Post by revelator »

Btw does anyone know where to get the sources for telejano quake ?, the old site is down and googling it only turns up links for the engine itself.
Productivity is a state of mind.
frag.machine
Posts: 2126
Joined: Sat Nov 25, 2006 1:49 pm

Re: Old sources crash when compiled in fully updated win 7

Post by frag.machine »

revelator wrote:Btw does anyone know where to get the sources for telejano quake ?, the old site is down and googling it only turns up links for the engine itself.
Well I have a .zip with Telejano 5 sources here, don't know if it's the latest but better than nothing. Send me a PM so we can figure out how I can make it available to you (may Google Drive or something like that).
I know FrikaC made a cgi-bin version of the quakec interpreter once and wrote part of his website in QuakeC :) (LordHavoc)
revelator
Posts: 2621
Joined: Thu Jan 24, 2008 12:04 pm
Location: inside tha debugger

Re: Old sources crash when compiled in fully updated win 7

Post by revelator »

PM sent :) and thanks.

Found the problem with my old realm engine's slowness, its caused by the lack of compiled vertex array support,
which i unfortunatly had to remove because newer cards crash when it is enabled.
Found that one out by building the unmodified MHQuake8 version.
I have a feeling this engine will need a rather hefty restructuring before it hits the same speeds that it had all those years ago :/
But in the end it might be for the better, would also allow me to get GLSL shader support in from remakequake and probably batch rendering.
Productivity is a state of mind.
Knightmare
Posts: 63
Joined: Thu Feb 09, 2012 1:55 am

Re: Old sources crash when compiled in fully updated win 7

Post by Knightmare »

This crash first started happening in September 2009, when the GL extension string first passed the 4KB mark in nVidia's drivers.

Ironically, QuakeEvolved 0.40, which one would have thought had all these vulnerabilities fixed, started crashing in the last couple of weeks when I updated my video drivers- I'd stayed on the nVidia 34x.xx driver for too long, and the new drivers have a GL extension string that exceeds 8KB, which is the size of Q2E's printmessage buffer. Q2E was also using vsnprintf() that while size-limited, wasn't null-terminated.

My advice is to first replace of all uses of vsprintf() with a null-terminated version of _vsnprintf():

Code: Select all

#ifdef _MSC_VER	// _WIN32
//#define Q_vsnprintf _vsnprintf
__inline int Q_vsnprintf (char *Dest, size_t Count, const char *Format, va_list Args) {
	int ret = _vsnprintf(Dest, Count, Format, Args);
	Dest[Count-1] = 0;	// null terminate
	return ret;
}
#else
// TODO: do we need Mac define?
#define Q_vsnprintf vsnprintf
#endif
Then just don't print the GL_EXTENSIONS string on startup. It's not needed and is so massive now that it fills most of the console buffer.

Third, if your project has a gl_strings or gfxinfo console command like Quake2 does, have it tokenize the GL extension string and only print 2 or 3 extensions at a time to a single line.
Spike
Posts: 2914
Joined: Fri Nov 05, 2004 3:12 am
Location: UK
Contact:

Re: Old sources crash when compiled in fully updated win 7

Post by Spike »

glGetString(GL_EXTENSIONS); has been deprecated since gl3

Code: Select all

GLint n, i;
glGetIntegerv(GL_NUM_EXTENSIONS, &n);
for (i = 0; i < n; i++) {
printf("%s\n", glGetStringi(GL_EXTENSIONS, i);
}
that's the new way. each extension is now its own string. there's no substring searching issues that need handling, there's no single-massive-buffer-with-resulting-overflows etc.
unfortunately glGetStringi only exists in gl3 so it doesn't really get you much.

and yes, using stack with limited buffer sizes sucks. that stuff is GOING to break, in remotely-exploitable ways.
revelator
Posts: 2621
Joined: Thu Jan 24, 2008 12:04 pm
Location: inside tha debugger

Re: Old sources crash when compiled in fully updated win 7

Post by revelator »

Aye i use the way spike mentioned now :) slowly getting after it again.
Productivity is a state of mind.
Post Reply