Gammon Forum : MUDs : General : Mud crash with roomflag nofloor

Log on

Gammon Forum

Entire forum

MUDs

General

Mud crash with roomflag nofloor

Mud crash with roomflag nofloor

It is now over 60 days since the last post. This thread is closed. Refresh page

Posted by Gunner Argentina (30 posts) bio

Date Tue 13 Oct 2020 01:30 PM (UTC)

Message

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

top

Posted by

Nick Gammon Australia (22,988 posts)

bio Forum Administrator

Date

Reply #1 on Tue 13 Oct 2020 08:25 PM (UTC)

Message

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

- Nick Gammon

www.gammon.com.au, www.mushclient.com

top

Posted by

Fiendish USA (2,514 posts)

bio Global Moderator

Date

Reply #2 on Tue 13 Oct 2020 08:43 PM (UTC)

Amended on Wed 14 Oct 2020 12:31 AM (UTC) by Fiendish

Message

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.

https://github.com/fiendish/aardwolfclientpackage

top

Posted by

Gunner Argentina (30 posts)

bio

Date

Reply #3 on Wed 14 Oct 2020 01:34 PM (UTC)

Message

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

top

Posted by Fiendish USA (2,514 posts) bio Global Moderator

Date

Reply #4 on Wed 14 Oct 2020 03:07 PM (UTC)

Amended on Wed 14 Oct 2020 10:16 PM (UTC) by Fiendish

Message

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.

https://github.com/fiendish/aardwolfclientpackage

top

Posted by Gunner Argentina (30 posts) bio

Date

Reply #5 on Thu 15 Oct 2020 12:33 AM (UTC)

Amended on Thu 15 Oct 2020 04:15 AM (UTC) by Nick Gammon

Message

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.

top

Posted by

Fiendish USA (2,514 posts)

bio Global Moderator

Date

Reply #6 on Thu 15 Oct 2020 01:54 AM (UTC)

Amended on Thu 15 Oct 2020 01:59 AM (UTC) by Fiendish

Message

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

https://github.com/fiendish/aardwolfclientpackage

top

Posted by Nick Gammon Australia (22,988 posts) bio Forum Administrator

Date Reply #7 on Thu 15 Oct 2020 04:17 AM (UTC)

Message

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

www.gammon.com.au, www.mushclient.com

top

Posted by Nick Gammon Australia (22,988 posts) bio Forum Administrator

Date Reply #8 on Thu 15 Oct 2020 04:20 AM (UTC)

Message

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).

- Nick Gammon

www.gammon.com.au, www.mushclient.com

top

Posted by Gatewaysysop2 USA (146 posts) bio

Date

Reply #9 on Sat 17 Oct 2020 09:17 PM (UTC)

Amended on Sat 17 Oct 2020 09:18 PM (UTC) by Gatewaysysop2

Message

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?

"The world of men is dreaming, it has gone mad in its sleep, and a snake is strangling it, but it can't wake up." -D.H. Lawrence

top

Posted by

Fiendish USA (2,514 posts)

bio Global Moderator

Date

Reply #10 on Sat 17 Oct 2020 09:55 PM (UTC)

Amended on Sat 17 Oct 2020 10:06 PM (UTC) by Fiendish

Message

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.

https://github.com/fiendish/aardwolfclientpackage

top

Posted by

Gatewaysysop2 USA (146 posts)

bio

Date

Reply #11 on Sat 17 Oct 2020 10:10 PM (UTC)

Message

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.

"The world of men is dreaming, it has gone mad in its sleep, and a snake is strangling it, but it can't wake up." -D.H. Lawrence

top

Posted by

Nick Gammon Australia (22,988 posts)

bio Forum Administrator

Date

Reply #12 on Sun 18 Oct 2020 06:52 AM (UTC)

Message

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

www.gammon.com.au, www.mushclient.com

top

Posted by

Nick Gammon Australia (22,988 posts)

bio Forum Administrator

Date

Reply #13 on Sun 18 Oct 2020 06:53 AM (UTC)

Message

Quote:

_why_ do we want to dump someone in limbo?

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

- Nick Gammon

www.gammon.com.au, www.mushclient.com

top

Posted by

Gatewaysysop2 USA (146 posts)

bio

Date

Reply #14 on Sun 18 Oct 2020 06:02 PM (UTC)

Amended on Sun 18 Oct 2020 06:03 PM (UTC) by Gatewaysysop2

Message

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?

"The world of men is dreaming, it has gone mad in its sleep, and a snake is strangling it, but it can't wake up." -D.H. Lawrence

top

The dates and times for posts above are shown in Universal Co-ordinated Time (UTC).

To show them in your local time you can join the forum, and then set the 'time correction' field in your profile to the number of hours difference between your location and UTC time.

27,790 views.

It is now over 60 days since the last post. This thread is closed. Refresh page

Go to topic: Search the forum

top

Quick links: MUSHclient. MUSHclient help. Forum shortcuts. Posting templates. Lua modules. Lua documentation.

Information and images on this site are licensed under the Creative Commons Attribution 3.0 Australia License unless stated otherwise.