Poop

The above issue occurred within the last six months. I’ve been coding here for 5+ years and there weren’t any issues rebooting before. So nope.

... Yes, my code must have been tampered, yet for some reason you had the same issue

Sounds like you got tampered code.

In my opinion the original coding of the reboot purge and wipes was written poorly, I remember my copy crashing on me when trying to initiate it. I found it easier to remove those calls from the reboot command and make them standalone, as well as automated them to fire off every 30 days for purge and 180 days for wipe.

There wasn't anything actually wrong with the bools in this scenario. Or the arguments. Not sure what you're saying here.

OR just rewrite the buggy code to carry over the bools and args properly?

I wouldn't. I would printf() at key locations of the invocation and force a REBOOT_PURGE, and narrow down the problem location. Or import the code to an IDE and run it on debug, with a break line on REBOOT_PURGE. printf() is #1 king of debug santa little helpers. Sometimes you just can't debug something as big a 7^4 iterations. You can output to that stuff to a file and check a pattern.

Just glanced at this, but a simple syntax error here or more likely we are missing more of the function (I'm not familiar if or how gdb truncates its output): purge_players(IS_SET(reboot_act, REBOOT_PURGE), vs purge_players(IS_SET(reboot_act, REBOOT_PURGE)); So load it with gdb -> break purge_players, command the mud to purge players, then just step line by line until you find your issue. Also not really sure why fCount=32 ' ' is missing a value, but probably not a crash. I really have no idea what it means. But basically, if you have seen this gdb output, it has already told you which functions to investigate and where they are found. Review them carefully at the crash point in the relevant *.c file. If you can't spot the error, do it line by line with gdb as described above.

Once in the debugger and going to the said line which created the crash I'd set a line break and step through the process to see when an error is occurred ( when an invalid memory space is accessed or resource (array or such) is effected which I didn't mean to.) Though I've only glanced through the code it seems that the "(name,name)" could be the issue, since it may be calling upon the same variable/decleration. Having no access to the rest of the code makes this hard to discern, More of a network guy but I think this is really a really cool group..

GDB is integral to debugging the Forsaken Lands. Oddly, and randomly at that, code likes to break. This can be caused by editing a function that you thought was only going to affect a skill or spell, and/or caused by random memory issues. When the MUD dies, it generates a core file. This core file helps debug what caused the issue, and the steps leading up to the crash or memory kill. For instance, just recently, we've been having crashes while running REBOOT_PURGE (which purges all the players who don't have enough hours). This is fixed already, however, perhaps someone can walk me through how you'd debug the following core file: #5 0x082283ed in free_string (str=0xa0ab59c "armor") at recycle.c:1552 1552 if( !str || str == &str_empty[0] ) (gdb) up #6 0x0823e19f in fread_char (ch=0xb62f1a00, fp=0xa0aa9e8) at save.c:1645 1645 skill = one_argument_2( name, name ); (gdb) up #7 0x08240efe in load_char (d=0xb62f0ba8, name=0xa1129a7 "Survihyal") at save.c:1234 1234 for ( iNest = 0; iNest < MAX_NEST; iNest++ ) (gdb) up #8 0x08143fd1 in purge_players (fPurge=2 '\002', fWipe=0 '\000', fCount=32 ' ', fLimited=0 '\000') at db.c:2835 2835 fFound = load_char (d, Dir->d_name); (gdb) up #9 0x0814e8d0 in boot_db (fHotReboot=1 '\001') at db.c:3268 3268 purge_players(IS_SET(reboot_act, REBOOT_PURGE), (gdb) up #10 0x08117f60 in main (argc=5, argv=0xbf9a6624) at comm.c:377 377 boot_db (fHotReboot);