When config files attack

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
qbism
Posts: 1236
Joined: Thu Nov 04, 2004 5:51 am
Contact:

When config files attack

Post by qbism »

Tracking down errors related to config files-

Any ideas for well-placed Con_Dprints or similar means to trace parsing/execution of config files? Or maybe more error-checking?

Spent several evenings chasing a protocol error, something that caused a crash right after map load, but turned out to be (apparently) a buggy default.cfg. Haven't found an actual bug in the cfg yet, but reverting to an older default.cfg magically solved the problem.
Teiman
Posts: 311
Joined: Sun Jun 03, 2007 9:39 am

Re: When config files attack

Post by Teiman »

qbism wrote: Any ideas for well-placed Con_Dprints or similar means to trace parsing/execution of config files? Or maybe more error-checking?
humm??... I don't think I totally understand what you mean, but maybe what you need is to create (engineside) a new exec command that "trace" the commands that hare added to the execution buffer. something like..he... "exectrace", and change quake.rc to have "exectrace config.cfg". Or a special cvar bug_tracing, that if is on, dump the executed stuff on console, this can be usefull to see these +left ; +jump; stuff.... maybe.

The last option is once you have figured out what is the culprit, report the problem to others enginecoders. I don't think a simple cfg file or command sould be able to crash quake. If a cfg setup can crash quake (other than something ridiculous like setting resolution to a billion and restarting) is a bug of such engine, and must be fixed.
mh
Posts: 2292
Joined: Sat Jan 12, 2008 1:38 am

Post by mh »

Even stock ID Quake contains a number of conditions that can cause crashes or undefined behaviour based on cvar values. These can include out-of-range values, division by zero, writing strings to float or integer cvars, NaN exceptions, string buffer overflows, etc. Some of these cvars may not be used until a client becomes active in a server (running a map).

It's very possible for a bad cfg to crash Quake.

What I'd do is diff the bad cfg with a known good one, go through each change from top to bottom of the file one at a time and add them to the known good one, thereby identifying the one that causes the crash.
We had the power, we had the space, we had a sense of time and place
We knew the words, we knew the score, we knew what we were fighting for
Downsider
Posts: 621
Joined: Tue Sep 16, 2008 1:35 am

Post by Downsider »

Or you could print the command being executed to the screen/to a file, then see which one it stops at.
c0burn
Posts: 208
Joined: Fri Nov 05, 2004 12:48 pm
Location: Liverpool, England
Contact:

Post by c0burn »

-condebug?
metlslime
Posts: 316
Joined: Tue Feb 05, 2008 11:03 pm

Post by metlslime »

config file contents are dumped into the command buffer, so you would probably want to put a breakpoint somewhere in the code where each command/cvar is evaluated, so you can step through one at a time until it crashes.
Spike
Posts: 2914
Joined: Fri Nov 05, 2004 3:12 am
Location: UK
Contact:

Post by Spike »

-condebug + echo

or just do a binary search - split the config in two and add/remove huge chunks at a time to narrow down the line that causes the issue.

or just run it in a debugger. that works too. :s
qbism
Posts: 1236
Joined: Thu Nov 04, 2004 5:51 am
Contact:

Post by qbism »

Thanks for the ideas!

Phase 1

In Cbuf_Execute I added a Con_DPrintf:

Code: Select all

.
.
.
// execute the command line
		Con_DPrintf("Cmd_ExecuteString: %s \n", line);  //qbism debug
		Cmd_ExecuteString (line, src_command);
.
.
.
I ran with "developer 1" in a windowed video mode and learned that the buggy default.cfg parses completely. There's no crash until changing to a map with frikbot waypoints in multiplayer. The last lines from the Con_DPrintf are all SCRATCH and SAVED type commands, matching the pattern of a waypoint dump. There's no actual problem with the bots or waypoints running a non-buggy default.cfg.


Phase 2

Next I'll start dividing and conquering the default.cfg by halves.
qbism
Posts: 1236
Joined: Thu Nov 04, 2004 5:51 am
Contact:

Post by qbism »

... well phase 2 didn't take long. A certain combination of two cvar values initiates the crash, no clue why! Makaqu has sv_aim and sv_aim_h to control aim assistance. Legal values are 0 to 1, and 1 is off. Setting either to 1 in default.cfg = crash. The same thing in config.cfg does NOT crash! Weird unsolved detail, but will let that mystery remain for now.

Some may say that the presence of autoaim brought on a config curse, but it was added for console controllers by the Dreamcast port author and might have use for other mouse-less platforms.
Last edited by qbism on Thu Feb 18, 2010 5:44 pm, edited 1 time in total.
Teiman
Posts: 311
Joined: Sun Jun 03, 2007 9:39 am

Post by Teiman »

qbism wrote: Legal values are 0 to 1, and 1 is off. Setting either to 1 in default.cfg = crash. The same thing in default.cfg does NOT crash! .
what?. I don't understand if it crash or not.

could be that this cvar is not defined (memory allocated) yet or something like that?
qbism
Posts: 1236
Joined: Thu Nov 04, 2004 5:51 am
Contact:

Post by qbism »

default.cfg does NOT crash!
Sorry, I made a typo, I meant to say "config.cfg does not crash" (original post edited).

So, setting those particular cvars to 1 in default.cfg will lead to the crash. Setting the same cvars to 1 in config.cfg will not. I say "lead to" because so far I don't see a link between the cause and effect.

BTW, I'm working on an 8-bit SW Quake and Flashquake based on Makaqu 1.3. When it's a little more presentable, will release an alpha.
Spike
Posts: 2914
Joined: Fri Nov 05, 2004 3:12 am
Location: UK
Contact:

Post by Spike »

sounds like there's a bug somewhere in the zone memory.

assuming sv_aim is 1, doing 'sv_aim 1' again has a check to prevent the exta free+malloc+strcpy. doing 'sv_aim 0', you will get an extra free+malloc.
does changing sv_aim during a map kill anything?
mneh, I dunno.
qbism
Posts: 1236
Joined: Thu Nov 04, 2004 5:51 am
Contact:

Post by qbism »

a bug somewhere in the zone memory.
Thanks, looks like you nailed it!

I had replaced Z_ClearZone, etc. with C functions to dynamically allocate (well actually via Q_malloc, etc.) Frankly over my head with it but didn't have a problem until now. I reverted back to the original zone code (bleh), and Z_Malloc "failed on 7900 bytes" while parsing bot waypoints. Boosting the DYNAMIC_SIZE up to 256k removed the crash.
Teiman
Posts: 311
Joined: Sun Jun 03, 2007 9:39 am

Post by Teiman »

Boosting the DYNAMIC_SIZE up to 256k removed the crash.
looks like a buffer overflow
qbism
Posts: 1236
Joined: Thu Nov 04, 2004 5:51 am
Contact:

Post by qbism »

Yes, default buffer is only 48k. Too small to parse waypoints. I noticed that Fitzquake is set to 256k and Qrack is 512k.
Post Reply