If there is a memory leak, there is a memory leak. Not giving the process memory will only result in it crashing or aborting. When you set a limit if the process tries to go past it fails trying to allocate memory, for hlds this is fatal, imagine hlds is trying to allocate memory for a new player that joined, only it couldn't allocate the space to store their name or steam id. You get the idea. Valve or gnu or where ever the actual problem lies needs to fix it.
-sb On 1/8/06, Joseph Laws <[EMAIL PROTECTED]> wrote: > Shouldn't the binary control itself in some fashion. That's like > operating a runaway train and instead of fixing the problem you give it > less track so it can't pickup speed... > > Kyle Lutze wrote: > > > I'm curious, why don't you guys try running in a quota'ed environment so > > *ds can't use more than 30% of your cpu and no more than 150megs of ram. > > Also, run it in gdb, so gdb ./srcds or whatever, then in gdb go run +all > > -options +here > > > > make sure it won't restart on crash > > when it crashes, run backtrace, then post the backtrace, the crash > > error, what version of *ds you are using, that could help a lot in > > debugging these issues > > > > Kyle > > > > _______________________________________________ > > 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
