Question IDNUMs

Well, I'm here again to ask questions about IDNUMs. I've been able to start detecting issues in regards to idnums getting out of whack in stock TBAMUD. I still haven't been able to exactly point out what is the issue, or how it is possible so I leave you all with this question.

How is it possible that TBAMUD could generate an IDNUM of 0, in accordance to the stock TBAMUD code? I've noticed the problem of creating really large IDNUMs for no reason stems from a new character creation, and a player gets a 0 idnum, and the mud recognizes that the IDNUM is in use, and it removes and adds the character again to the index and essentially crashes the mud. Upon restart of the MUD the character in question will have a screwed up IDNUM of like 1.3 billion.

Here is an example of the crashlog that ensues, and keep in mind GDB does not return any useable details from the stack:

> File: crash; Min. Level to read: 42; File Location: ../syslog.CRASH
> File size (bytes): 1747; Total num lines: 30
> Reading from the tail of the file.
> Apr 14 00:33:44 :: Invalid command goto taelo by Calin.
> Apr 14 00:35:30 :: WARNING: EOF on socket read (connection broken by
> peer)
> Apr 14 00:35:30 :: Closing link to: JehobaWidness.
> Apr 14 00:35:51 :: RUs: an off duty guard -(100)-> Henry
> Apr 14 00:36:42 :: Calin has re-logged in ... disconnecting old
> socket.
> Apr 14 00:37:03 :: (GC) Grifter snoops Taelo
> Apr 14 00:37:08 :: SYSERR: init_char: Character "Calin" not found in
> player table.
> Apr 14 00:37:18 :: Add_to_lookup failed. Already there. (uid = 0)
> Apr 14 00:37:18 :: Calin retrieving crash-saved items and entering
> game.
> Apr 14 00:37:18 :: Calin (level 1) has 11 objects (max 300). (<-- this char was level 5 before hand)
> Apr 14 00:37:18 :: Calin (level 1) has 0 bionics.
> Apr 14 00:40:23 :: SYSERR: CHECKPOINT shutdown: tics not updated.
> (Infinite loop suspected)
> Quick boot mode -- rent check supressed.
> Using log file "syslog" with redirection.
>
>
> Aborted (core dumped)
> 15 lines returned.

Is this reproducible?

This is not something I've been able to reproduce effectively. It will just randomly happen, from what i can tell, no particular reason at all. Obviously there is a reason, but I cant figure out why. My _GUESS_ is, that someone creates a character, doesn't make it all the way through character creation, and ends up with a 0 IDNUM, or receives a 0 IDNUM for whatever reason after entering the game, and it will completely throw the game out of whack for the next player. I'd appreciate suggestions, as i've been trying to sort out this bug for ages.

Okay, so I think I found a way to replicate the issue (Sort of)

1) Make a new character.
2) Enter the game through character creation.
3) With an immortal character "set" the deleted flag on that level 1 character.
4) Have that character log out normally. (This may also work with having the character delete himself through the login screen, but we don't offer that option)
5) Make a new character with the same name as before.
6) Enter the game through character creation.

*** This players IDNUM is now set to 0, for some reason.

Create a new connection to the mud with your immortal and IDNUM 0 player still logged in, and have them create a new character.

Before finishing character creation, the new character will overtake the IDNUM 0 character without providing a password and the mud will enter an infinite loop.

This, to me, does not make any sense, I am using the stock login/deletion/indexing system that newest TBAMud uses. Perhaps you can duplicate it.

If anyone has any ideas, suggestions, or would like to look for themselves and provide feedback, I will genuinely appreciate it. This has been bugging me for months.

1) Make character X
2) Enter game
3) Use Immortal Y to set the 'deleted' flag on character X
4) Log out character X
5) Make character Z with character X's name
6) Enter game
7) Create character K and enter them into game with Immortal Y and character Z

I'll test it out...

I assume you used the 'user' command to identify the player IDNUMs.

Couldn't reproduce it...