InsideQC Forums

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.

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.

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.

Or you could print the command being executed to the screen/to a file, then see which one it stops at.

-condebug?

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.

-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

Thanks for the ideas!

Phase 1

In Cbuf_Execute I added a Con_DPrintf: 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.

... 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.

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?

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.

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.

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.

Boosting the DYNAMIC_SIZE up to 256k removed the crash.

looks like a buffer overflow

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