Inside3D!
     

When config files attack

 
Post new topic   Reply to topic    Inside3d Forums Forum Index -> General Programming
View previous topic :: View next topic  
Author Message
qbism



Joined: 04 Nov 2004
Posts: 82

PostPosted: Wed Feb 17, 2010 6:54 am    Post subject: When config files attack Reply with quote

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
View user's profile Send private message Visit poster's website
Teiman



Joined: 03 Jun 2007
Posts: 309

PostPosted: Wed Feb 17, 2010 1:36 pm    Post subject: Re: When config files attack Reply with quote

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
View user's profile Send private message
mh



Joined: 12 Jan 2008
Posts: 909

PostPosted: Wed Feb 17, 2010 4:39 pm    Post subject: Reply with quote

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
View user's profile Send private message Visit poster's website
Downsider



Joined: 16 Sep 2008
Posts: 477

PostPosted: Wed Feb 17, 2010 8:38 pm    Post subject: Reply with quote

Or you could print the command being executed to the screen/to a file, then see which one it stops at.
Back to top
View user's profile Send private message
c0burn



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

PostPosted: Wed Feb 17, 2010 8:51 pm    Post subject: Reply with quote

-condebug?
Back to top
View user's profile Send private message Visit poster's website AIM Address MSN Messenger
metlslime



Joined: 05 Feb 2008
Posts: 177

PostPosted: Wed Feb 17, 2010 9:26 pm    Post subject: Reply with quote

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
View user's profile Send private message
Spike



Joined: 05 Nov 2004
Posts: 944
Location: UK

PostPosted: Wed Feb 17, 2010 10:13 pm    Post subject: Reply with quote

-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
View user's profile Send private message Visit poster's website
qbism



Joined: 04 Nov 2004
Posts: 82

PostPosted: Thu Feb 18, 2010 1:22 am    Post subject: Reply with quote

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
View user's profile Send private message Visit poster's website
qbism



Joined: 04 Nov 2004
Posts: 82

PostPosted: Thu Feb 18, 2010 1:56 am    Post subject: Reply with quote

... 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
View user's profile Send private message Visit poster's website
Teiman



Joined: 03 Jun 2007
Posts: 309

PostPosted: Thu Feb 18, 2010 2:06 pm    Post subject: Reply with quote

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
View user's profile Send private message
qbism



Joined: 04 Nov 2004
Posts: 82

PostPosted: Thu Feb 18, 2010 5:55 pm    Post subject: Reply with quote

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
View user's profile Send private message Visit poster's website
Spike



Joined: 05 Nov 2004
Posts: 944
Location: UK

PostPosted: Thu Feb 18, 2010 6:09 pm    Post subject: Reply with quote

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
View user's profile Send private message Visit poster's website
qbism



Joined: 04 Nov 2004
Posts: 82

PostPosted: Fri Feb 19, 2010 7:03 am    Post subject: Reply with quote

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
View user's profile Send private message Visit poster's website
Teiman



Joined: 03 Jun 2007
Posts: 309

PostPosted: Fri Feb 19, 2010 10:02 pm    Post subject: Reply with quote

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


looks like a buffer overflow
Back to top
View user's profile Send private message
qbism



Joined: 04 Nov 2004
Posts: 82

PostPosted: Sat Feb 20, 2010 12:23 am    Post subject: Reply with quote

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
View user's profile Send private message Visit poster's website
Display posts from previous:   
Post new topic   Reply to topic    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