Mud crash with roomflag nofloor

Posted by Gunner on Tue 13 Oct 2020 01:30 PM — 15 posts, 53,540 views.

Gunner Argentina Tue 13 Oct 2020 01:30 PM #0

Hi.
I'm using codebase Swfote 2.1.
when I use the nofloor flag in a room and i'm falling down, the mud crashess.
The error is:

#0  0x00000000004ddd52 in char_to_room (ch=0x12e7490, pRoomIndex=0x0) at handler.c:1098

That line of handler.c is:

void char_to_room( CHAR_DATA *ch, ROOM_INDEX_DATA *pRoomIndex )
{
    OBJ_DATA *obj;

    if ( !ch )
    {
	bug( "Char_to_room: NULL ch!", 0 );
	return;
    }
   if( !get_room_index( pRoomIndex->vnum ) )
      pRoomIndex = NULL;

And the nofloor flag code in the act_move.c file is:

bool will_fall( CHAR_DATA *ch, int fall )
{
    if ( IS_SET( ch->in_room->room_flags, ROOM_NOFLOOR )
    &&   CAN_GO(ch, DIR_DOWN)
    && (!IS_AFFECTED( ch, AFF_FLYING )
    || ( ch->mount && !IS_AFFECTED( ch->mount, AFF_FLYING ) ) ) )
    {
	if ( fall > 80 )
	{
	   bug( "Falling (in a loop?) more than 80 rooms: vnum %d", ch->in_room->vnum );
	   char_from_room( ch );
	   char_to_room( ch, get_room_index( wherehome(ch) ) );
	   fall = 0;
	   return TRUE;
	}
	set_char_color( AT_FALLING, ch );
	send_to_char( "Caes...\n\r", ch );
	move_char( ch, get_exit(ch->in_room, DIR_DOWN), ++fall );
	return TRUE;
    }
    return FALSE;
}

Thank you in advance and sorry for my English

Nick Gammon Australia Forum Administrator Tue 13 Oct 2020 08:25 PM #1

Please indicate which line is 1098. Also show the backtrace (bt) so we can see which line in "will_fall" you are at.

Fiendish USA Global Moderator Tue 13 Oct 2020 08:43 PM #2

Given "pRoomIndex=0x0" in the error, line 1098 is probably "if( !get_room_index( pRoomIndex->vnum ) )".

Which means that "get_room_index( wherehome(ch) )" is returning NULL.

Quote:
I'm using codebase Swfote 2.1.

Gunner, please don't do that. Link to a download of the codebase. We don't know what "swfote 2.1" means to you. You could have gotten it from anywhere. And now I can't go any further because you haven't linked to the source.

Gunner Argentina Wed 14 Oct 2020 01:34 PM #3

Sorry. Here is the codebase.
http://www.mudbytes.net/files/818/

It's strange, since it doesn't always crash and I don't know why that happens. Rooms always exist, as the nofloor flag only runs if there is a down exit.

Tahnk

Fiendish USA Global Moderator Wed 14 Oct 2020 03:07 PM #4

You still need to give the full backtrace like Nick asked for and not just the last step. I'm only guessing that the code got to char_to_room from will_fall, but don't know for sure.

But more importantly, if I'm right, then you need to figure out why get_room_index(wherehome(ch)) is returning NULL for your character.

Quote:
I don't know why that happens.

You see that the problem is in char_to_room. You see that char_to_room is called in will_fall. You see what decisions are being made at each line of code to determine what happens when. Even if you didn't know that it was bad for pRoomIndex to be 0x0 there (which now you definitely do because I've told you*), you should still be looking at precursor events to understand the sequence of events in the code that led to the failure.

Code executes in the given order according to the given evaluation rules. You should know that the only way for pRoomIndex to be 0x0 in char_to_room is for it to be passed in that way. You should know that the only way for it to be passed in that way is if the thing that happened before made that happen. Now it's on you to figure out why.

* - The exact line of the error, if I'm right, and which would have been clear if you'd done what Nick asked for and actually showed us line numbers, is


   if( !get_room_index( pRoomIndex->vnum ) )

Given that the error is on that line and not a line inside of get_room_index, that means by elimination that the problem is with the invocation of

pRoomIndex->vnum

You cannot reference the vnum of a pRoomIndex that is NULL (0x0), which means that pRoomIndex being NULL is not expected and is probably not OK. That ties our error message to the point of failure. You have to walk backwards in time to figure out how it happened.

Gunner Argentina Thu 15 Oct 2020 12:33 AM #5

Hi.

I have not been able to send the backtrace before, because I had deleted the core and the crash does not always happen, it had not been generated until now.

Quote:

"But more importantly, if I'm right, then you need to figure out why get_room_index(wherehome(ch)) is returning NULL for your character."

Shure, get_room_index(wherehome(ch)) shouldn't return null.

The bt is:


(gdb) bt
#0  0x00000000004ddd52 in char_to_room (ch=0xd13340, pRoomIndex=0x0) at handler.c:1098
#1  0x00000000004a52c4 in copyover_recover () at copyover.c:1198
#2  0x00000000004a91e2 in boot_db (fCopyOver=1 '\001') at db.c:931
#3  0x000000000049584f in main (argc=5, argv=0x7fff6dbbb428) at comm.c:257

handler.c, in function char_to_room:
1098.    if( !get_room_index( pRoomIndex->vnum ) )
1099.       pRoomIndex = NULL;
1101.    if ( !pRoomIndex )
1102.    {
1103. char buf[MAX_STRING_LENGTH];

1105: 	sprintf( buf, "Char_to_room: %s -> NULL room!  Putting char in limbo (%d)",
		ch->name, ROOM_VNUM_LIMBO );
	bug( buf, 0 );
        /* This used to just return, but there was a problem with crashing
           and I saw no reason not to just put the char in limbo. -Narn */
        pRoomIndex = get_room_index( ROOM_VNUM_LIMBO );
    }

copyover.c:
Line 1198. 	char_to_room( d->character, d->character->in_room );

Line 931 from db.c onli calls copyover_recover function.
Line 257 from comm.c calls boot_db.

Indeed, at some point pRoomIndex becomes null, but I do not know if in the will_fall function or in the char_to_room function because it's not something that happens all the time.

Fiendish USA Global Moderator Thu 15 Oct 2020 01:54 AM #6

Quote:
at some point pRoomIndex becomes null, but I do not know

You need to find out.

http://www.cs.yale.edu/homes/aspnes/pinewiki/C(2f)Debugging.html

Nick Gammon Australia Forum Administrator Thu 15 Oct 2020 04:17 AM #7

Also see my page about debugging MUD crashes with gdb:

http://gammon.com.au/debug

Judging by the backtrace it is something to do with copyover:


#1  0x00000000004a52c4 in copyover_recover () at copyover.c:1198

Would you be booting/rebooting at the time?

Nick Gammon Australia Forum Administrator Thu 15 Oct 2020 04:20 AM #8

Basically what that is telling you is:


char_to_room( d->character, d->character->in_room );

You are calling char_to_room with 2 arguments.


char_to_room (ch=0xd13340, pRoomIndex=0x0) at handler.c:1098

The room argument is NULL (d->character->in_room).

So, during a copyover, this particular character appears to not be in a room. You either find out why and fix that, or make the code handle the fact that the room is unknown, eg. by forcing it to another room (probably not the ideal solution).

Gatewaysysop2 USA Sat 17 Oct 2020 09:17 PM #9

Have to say this is a bit difficult to follow.

If the problem is with falling, what has that to do with copyover? From the last backtrace, it would seem nothing to do with falling in particular, at least in that instance.

Based on Nick's comments below, the non-ideal fix was already in the codebase that you linked, i.e.


           /* Just In Case,  Someone said this isn't necassary, but _why_
              do we want to dump someone in limbo? */
           if (!d->character->in_room)
                d->character->in_room = get_room_index (ROOM_VNUM_TEMPLE);

           /* Insert in the char_list */
           LINK( d->character, first_char, last_char, next, prev );           

             char_to_room (d->character, d->character->in_room);

Did you by chance remove the "just in case" piece? Otherwise I'm struggling to see how this can happen in copyover_recover( ) in particular.

Have you made changes to the code?

Fiendish USA Global Moderator Sat 17 Oct 2020 09:55 PM #10

Quote:
If the problem is with falling, what has that to do with copyover?

The problem isn't caused by falling. It just manifests then by trying to look inside a null. Nothing stops it from manifesting at other times too, because falling isn't where the null is created in the first place.

Gatewaysysop2 USA Sat 17 Oct 2020 10:10 PM #11

Fiendish said:

Quote:
If the problem is with falling, what has that to do with copyover?

We don't know that the problem has anything to do with falling. We just know that the OP said so and then showed some potentially misleading code snippets.

More or less what I was trying to convey with the question.

Seems some perhaps more general weirdness going on with in_room, but what... who knows at this point. If we had some idea what was changed, that might get you somewhere closer to a culprit.

Seems improbable (but not impossible) that this would be broken in a stock codebase if it is causing crashes on all sorts of places too, right? Falling may be uncommon, but copyover? Not so much.

Nick Gammon Australia Forum Administrator Sun 18 Oct 2020 06:52 AM #12

Are you looking at the right core file? You say it happens when you are falling, but nothing in the backtrace supports that.

Nick Gammon Australia Forum Administrator Sun 18 Oct 2020 06:53 AM #13

Quote:

_why_ do we want to dump someone in limbo?

So the server doesn't crash. However that doesn't appear to have worked.

Gatewaysysop2 USA Sun 18 Oct 2020 06:02 PM #14

Nick Gammon said:

Quote:

_why_ do we want to dump someone in limbo?

So the server doesn't crash. However that doesn't appear to have worked.

This is one of the things that confuses me. It seems the stock code already has that precaution in it, and yet from what the OP described it still crashed in this scenario. Not seeing how that would even be possible unless the code had been changed, e.g. someone removed that section from stock, or the VNUM is no longer valid or some such... right?