Well on my machine at least, GDB slows things down quite a bit, this slowdown is more likely to mitigate time-affected bugs like race conditions, debugging core dumps as described below is a much better option if you have it.
-sb On 1/17/06, Philip Lorenz <[EMAIL PROTECTED]> wrote: > Hi, > > You might simply let the srcds core-dump and then load the file using > gdb (ulimit -c unlimited will produce a core-dump on segfault (-debug > parameters enables this but limits the core size to 2000 which often is > not enough resulting in corrupt core dumps)). > > Regards, > > Philip Lorenz > > dackz wrote: > > > If you've been running into issues with the server crashing, you might > > find running the server under GDB useful for seeing where the server > > crashed. Of course the only problem with this is when GDB stops running > > the program, it just returns a command prompt and awaits your input, > > instead of restarting the server. > > > > This is the Bash script I'm using to start my DOD:S server right now: > > #!/bin/bash > > export LD_LIBRARY_PATH=".:bin:$LD_LIBRARY_PATH" > > dtach -n ./terminal.dod1 -r winch taskset 0x0000000C -- gdb -q -batch -x > > ./gdbinit \ > > --args ./srcds_i686 -debug \ > > -game dod \ > > -pidfile ../pid.dod1 \ > > -tickrate 33 \ > > +ip 1.2.3.4 \ > > +hostname "Hostname" \ > > +map dod_donner \ > > +maxplayers 26 \ > > > > dtach mimicks screen's detach feature and taskset relegates gdb and > > srcds to processors 2 and 3 (I'm running two processors with HT). > > Anyway, the good parts are gdb's switches. "-q" starts it in "quiet" > > mode, so it doesn't print anything except the prompt when you start it. > > "-batch" removes the prompt entirely and instead executes a series of > > commands specified in the file chosen by the "-x" switch. In my gdbinit > > file, I have the following: > > > > set logging on > > while 1 > > run > > bt > > end > > > > The first makes gdb log all of its own output to "gdb.txt" in the > > current working directory. "run" starts the program of course, and when > > the program finishes running, it runs "bt" (short for "backtrace"). If > > the server segfaults, this will print a backtrace of where it crashed. > > Or more simply, it'll print the function in which the server crashed, > > and the list of functions that were called to get to that point. > > > > After the program quits, it restarts it again. This is definitely useful > > for keeping the server up, but it can be annoying if you're trying to > > forcibly quit the server. If that's the case, you should probably just > > run "quit" once and then hit ^C two times to exit gdb. > > > > Anyway, hopefully someone will find this information useful. I'm really > > only running gdb on my production server at the moment because the > > source server crashes without it due to some sort of incompatibility > > with my kernel, but it's still useful for getting real crash information > > in real situations for reporting bugs. > > > > _______________________________________________ > > To unsubscribe, edit your list preferences, or view the list archives, > > please visit: > > http://list.valvesoftware.com/mailman/listinfo/hlds_linux > > > > _______________________________________________ > To unsubscribe, edit your list preferences, or view the list archives, please > visit: > http://list.valvesoftware.com/mailman/listinfo/hlds_linux > _______________________________________________ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlds_linux
