A couple of things on this actually: Firstly, if core dumps are limited, generally you won't get too far with this, simply because it's done for a reason. Core dumps generally take up a rather large amount of space (10m is a small core), and given the fact that individuals oversell resources (bandwidth, drives, etc) like crazy usually (it's the only way to make any money unfortunately doing hosting), you'll usually find that cores can't be adjusted. it's sad, but it's true.
Secondly, it's rather hard to determine how "large" a corefile will be. that's not saying it CAN'T be done, because, anything can be done with the right knowledge, time and dedication. In cases like this though, the best response is to run it in gdb and backtrace on dump. info On Wed, 2004-05-12 at 16:43, Richard Lindsey wrote: > I have a quick question just out of curiosity about the whole ulimit and > core dumping thing being discussed here... could one implement something > in the code to estimate how big of a core the mud will dump at any given > time (this way you only have to do it once as your mud expands in size) > and then use a signal handler to catch the segfaults and check the > availability of space assigned for core dumps, and use a system() call > to expand that size w/ a ulimit command before the mud actually tries to > dump a core? That way you'd never have to worry about there not being > enough space... > > Richard Lindsey > > -----Original Message----- > From: Tom Whiting [mailto:[EMAIL PROTECTED] > Sent: Wednesday, May 12, 2004 2:40 PM > To: [email protected] > Subject: Re: Segmentation Fault > > On Wed, 2004-05-12 at 15:04, [EMAIL PROTECTED] wrote: > > > I keep getting this message in my shell. No crashes, no core dumps, > just a > > > Segmentation fault, mud kills, then restarts. > > > > Are you running on Redhat? A couple years ago when I first moved our > mud > > to Redhat it would no longer dump core. The problem, as it turned > out, > > was the default system resource limit for core files was set at > something > > like 2 meg. Our mud tends to dump cores over 10meg, so this prevented > it > > from making any core files at all. > > > > Here is a snippet that will help you see if that kernel restriction is > > stopping core files from being generated. > > > No snippet is needed actually, simply type ulimit -a inside of the > shell. You'll see what your current limits are. If you're dumping cores > that are higher than your limit, then yes, it will bail on you. The best > way to find the problem in that case would be to run the mud in gdb (see > the rom faq on how to do that), set breakpoints and use backtrace when > it dies. Either that or use valgrind which is a decent tool as well. > Valgrind, however will (usually) only detect memory problems > > > -- > ROM mailing list > [email protected] > http://www.rom.org/cgi-bin/mailman/listinfo/rom
