> So I ran a debugger on the MUD and noticed that we had an error of "bad > memory allocation" or something like that. > > We figured it may have been a problem with the machine's memory not > reseting, so we rebooted the machine. Ionic (out other Imp) got on the > MUD, and everything worked fine, so we assumed the bug was fixed...wrong. > It seems that you (and alot of coders out there) don't know how to use the debugger utility properly. Here are a few hints: When you compile your mud, make sure you use the flag -g. Make sure that you have limit coredumpsize 1000 in your .login or .cshrc. When the mud crashes, it will dump memory into a file called 'core'. To examine this information, tybe dbx bin/circle (or however you have your directories set up). You'll get a bunch of cryptic information on the screen. Type where and hit return. On your screen will list the function that caused your program to die. It'll even show you the file name and line number! To exit dbx, type quit. A memory violation or memory allocation error is not a result of your machine going haywire, Ace. What a memory allocation error is that the program tried to copy something into memory when the program hadn't made room in memory for it previously (usually). -Adept
This archive was generated by hypermail 2b30 : 12/07/00 PST