Index | FAQ | Search | Memberlist | Usergroups | Profile | Log in to check your private messages | Log in | Register

When config files attack

| Inside3d Forums Forum Index -> General Programming

View previous topic :: View next topic
Author | Message
--- | ---
qbism Joined: 04 Nov 2004 Posts: 82 |

Posted: Wed Feb 17, 2010 6:54 am Post subject: 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.
_________________
http://qbism.com

Back to top |

Teiman Joined: 03 Jun 2007 Posts: 309 |

Posted: Wed Feb 17, 2010 1:36 pm Post subject: Re: When config files attack |

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.

Back to top |

mh Joined: 12 Jan 2008 Posts: 909 |

Posted: Wed Feb 17, 2010 4:39 pm Post subject: |

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.
_________________
DirectQ Engine - New release 1.8.666a, 9th August 2010
MHQuake Blog (General)
Direct3D 8 Quake Engines

Back to top |

Downsider Joined: 16 Sep 2008 Posts: 478 |

Posted: Wed Feb 17, 2010 8:38 pm Post subject: |

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

Back to top |

c0burn Joined: 05 Nov 2004 Posts: 158 Location: Liverpool, England |

Posted: Wed Feb 17, 2010 8:51 pm Post subject: |

-condebug?

Back to top |

metlslime Joined: 05 Feb 2008 Posts: 177 |

Posted: Wed Feb 17, 2010 9:26 pm Post subject: |

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.

Back to top |

Spike Joined: 05 Nov 2004 Posts: 944 Location: UK |

Posted: Wed Feb 17, 2010 10:13 pm Post subject: |

-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 _________________ What's a signature?

Back to top |

qbism Joined: 04 Nov 2004 Posts: 82 |

Posted: Thu Feb 18, 2010 1:22 am Post subject: |

Thanks for the ideas! Phase 1 In Cbuf_Execute I added a Con_DPrintf:

Code:
. . . // 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.
_________________
http://qbism.com

Back to top |

qbism Joined: 04 Nov 2004 Posts: 82 |

Posted: Thu Feb 18, 2010 1:56 am Post subject: |

... 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.
_________________
http://qbism.com
Last edited by qbism on Thu Feb 18, 2010 5:44 pm; edited 1 time in total

Back to top |

Teiman Joined: 03 Jun 2007 Posts: 309 |

Posted: Thu Feb 18, 2010 2:06 pm Post subject: |

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?

Back to top |

qbism Joined: 04 Nov 2004 Posts: 82 |

Posted: Thu Feb 18, 2010 5:55 pm Post subject: |

Quote:
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.
_________________
http://qbism.com

Back to top |

Spike Joined: 05 Nov 2004 Posts: 944 Location: UK |

Posted: Thu Feb 18, 2010 6:09 pm Post subject: |

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.
_________________
What's a signature?

Back to top |

qbism Joined: 04 Nov 2004 Posts: 82 |

Posted: Fri Feb 19, 2010 7:03 am Post subject: |

Quote:
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.
_________________
http://qbism.com

Back to top |

Teiman Joined: 03 Jun 2007 Posts: 309 |

Posted: Fri Feb 19, 2010 10:02 pm Post subject: |

Quote:
Boosting the DYNAMIC_SIZE up to 256k removed the crash.

looks like a buffer overflow

Back to top |

qbism Joined: 04 Nov 2004 Posts: 82 |

Posted: Sat Feb 20, 2010 12:23 am Post subject: |

Yes, default buffer is only 48k. Too small to parse waypoints. I noticed that Fitzquake is set to 256k and Qrack is 512k. _________________ http://qbism.com

Back to top |

Display posts from previous:

| Inside3d Forums Forum Index -> General Programming | All times are GMT
Page 1 of 1

Jump to:

You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum

Powered by phpBB © 2004 phpBB Group