When config files attack
When config files attack
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.
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.
Re: When config files attack
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.qbism wrote: Any ideas for well-placed Con_Dprints or similar means to trace parsing/execution of config files? Or maybe more error-checking?
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.
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
We knew the words, we knew the score, we knew what we were fighting for
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.
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);
.
.
.
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.
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.
Sorry, I made a typo, I meant to say "config.cfg does not crash" (original post edited).default.cfg does NOT crash!
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.
Thanks, looks like you nailed it!a bug somewhere in the zone memory.
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.