So it's incremented in Read_Invalid_List.

Where is Read_Invalid_List called?

act.wizard.c:void Read_Invalid_List(void);
act.wizard.c: Read_Invalid_List();
ban.c:void Read_Invalid_List(void);
ban.c:void Read_Invalid_List(void)
db.c:void Read_Invalid_List(void);
db.c: Read_Invalid_List();
db.c.orig:void Read_Invalid_List(void);
db.c.orig: Read_Invalid_List();
db.c.save:void Read_Invalid_List(void);
db.c.save: Read_Invalid_List();

This is the Section of code its in Ban.c

void Read_Invalid_List(void)
{
  FILE *fp;
  char temp[256];

  if (!(fp = fopen(XNAME_FILE, "r"))) {
    perror("SYSERR: Unable to open '" XNAME_FILE "' for reading");
    return;
  }

  num_invalid = 0;
  while (get_line(fp, temp) && num_invalid < MAX_INVALID_NAMES)
    invalid_list[num_invalid++] = str_dup(temp);

  if (num_invalid >= MAX_INVALID_NAMES) {
    log("SYSERR: Too many invalid names; change MAX_INVALID_NAMES in ban.c");
    exit(1);
  }

  fclose(fp);
}

You already posted that.

Can you print num_invalid before and after it's set in Read_Invalid_List?

Well, there is your crash cause, you are sending a NULL pointer to strstr(). Now
all you have to do is find where it is either looping past the end of the list, or not
setting a valid pointer (either on list load or reset to NULL later).

It might help if you print the file of names here, and also your str_dup() function
(I have seen some buggy code in some muds that read an empty string and save
it as NULL).

Ok, I missed this clue on my quick read before posting that last post.
Looks like it is reading past the end of the list. This is real odd though, from what
I can see in the code you posted, it looks like it is initialized to zero and only
incremented when a name is read, and the load reinitializing to zero before loading.

Might have a clue here, the number (assuming little endian) is ESC
Ok, I missed this clue on my quick read before posting that last post.
Looks like it is reading past the end of the list. This is real odd though, from what
I can see in the code you posted, it looks like it is initialized to zero and only
incremented when a name is read, and the load reinitializing to zero before loading.

Might have a clue here, the number (assuming little endian) is ESC[1; which is an
ANSI escape code for setting high intensity color. Maybe the global memory area
is being overwritten with data meant to be sent to the player. I would also look
for places you send this escape code (the ESC will be something like \033 or \x1B
in a string) and follow where it is sent (like to see if it might be overrunning a
buffer or something).

I vote for running with valgrind…

Hmmm sorry guys College got me a little busy, It seems that the mud host im using has Jailshell and its blocking me from gettin the Variables that you've requested. Even after talking to them i still can't get it to work…And as for the sharmair was talking about i dont see any of those things in Ban.c the only cases of those i can remember are in the the file that has to do with choosing your races and ect when you make a character.

It could be that the ANSI is being sent to another global variable and is over running its data area and
over writing your data. You could follow where that ANSI is sent, making sure all the places are large
enough to hold the data. Note though that this is just the first part of the ANSI color code. But that
might allow you to get more data if you look at all the memory around that variable (you MIGHT be
able to do something like 'print (char*)&num_invalid' to have it print the whole string from that point
until it hits a NUL - also, I am sure gdb has a way of getting a memory dump of a place in memory,
but I have never had to used gdb for this). Also note that the data that is overwriting your data might
very well start before this, so looking at the memory before this might give the whole string, and give
a better clue as to what is sending it, and from that where it is trying to send it. Then you can make
sure that is correct.

Doing the print i got this
(gdb) print (char*)&num_invalid
$1 = 0x8163dd4 "0"

And after a crash this came up
$1 = 0x8163dd4 ";0m\r\n"

You can print some variables from gdb but not others because of some program called Jailshell?

Correct, I can't put in breaks and rerun the mud with the breaks in it. Jailshell kicks in and stops it from running.

any one see anything helpful in this line?
$1 = 0x8163dd4 ";0m\r\n"

That looks like the tail end of a string, a bit of an odd one too. The ";0m" looks like the end
of one of those ANSI color codes I was talking about, but normally a 0 is the first part of a
multi part code (it is a reset after all). If you try adding negative offsets on that variable, you
should be able to get the full string. Use like 'print (char*)(&num_invalid-1)' to look at the
memory as a string starting a bit before num_invalid, then use larger numbers (meaning
more negative) to move back until the string you had vanishes (you go past the front and
also cross a NUL) or the new chars you see look random or out of place (you probably passed
the start and are into binary data). hopefully you will get a string that you will recognize.
Also not that you might have different strings on different crashes. But like I was thinking
before, it really looks like you are overrunning a buffer before this in memory, and you might
have been for a while but before it was over writing memory that did not cause a crash when
messed up.

Well thank you, you guys i was finally able to figure out that it was a color issue in the characters Prompt that was bleeding. After looking in the code then by double checking it by turning off the prompt of the player fighting and a player loggin in the mud didnt crash. So now all i have to do is look through the lines of the code that do the Prompt.

I did a peek at a version of circlemud I have on my computer (pretty much stock 3.0bpl19) and if
what you have is close to that, I would check that the static buffer (prompt) in the make_prompt
function is large enough for the prompts it has to hold (in the code I am looking at, it is 97 chars
- MAX_PROMPT_LENGTH + 1). Stock did not have any color, so if that was added, that can add a
lot of chars you don't see quick (a color change can top 14 chars - though 7 or so is probably more
average).

Hmmm nope shouldnt be the size of the Max_prompt_length thats set to 20000 words in Structs.H
When the crash happens using the -1 i can go all the way back to -14 before it returns to normal and it shows the prompt of the character fighting right before the crash.

Well I believe i figured it out completely, Who ever made the prompt for DBT decided to be lazy and not make a part of Practices and just included it on the Mana part of the prompt which was throwing it off course. I simply just removed the Practices part from the mana and the mud runs just fine now.