Login
User Name:

Password:



Register
Forgot your password?
Vote for Us!
Couple bugs
Dec 12, 2017, 5:42 pm
By Remcon
Bug in disarm( )
Nov 12, 2017, 6:54 pm
By GatewaySysop
Bug in will_fall( )
Oct 23, 2017, 1:35 am
By GatewaySysop
Bug in do_zap( ), do_brandish( )
Oct 18, 2017, 1:52 pm
By GatewaySysop
Bug in get_exp_worth( )
Oct 10, 2017, 1:26 am
By GatewaySysop
LOP 1.45
Author: Remcon
Submitted by: Remcon
LOP Heroes Edition
Author: Vladaar
Submitted by: Vladaar
Heroes sound extras
Author: Vladaar
Submitted by: Vladaar
6Dragons 4.3
Author: Vladaar
Submitted by: Vladaar
Memwatch
Author: Johan Lindh
Submitted by: Vladaar
Users Online
CommonCrawl, Yandex, DotBot, Bing

Members: 0
Guests: 10
Stats
Files
Topics
Posts
Members
Newest Member
477
3,705
19,232
608
LAntorcha
Today's Birthdays
There are no member birthdays today.
Related Links
» SmaugMuds.org » Codebases » SWR FUSS » char_to_room does not handle ...
Forum Rules | Mark all | Recent Posts

char_to_room does not handle null room correctly.
< Newer Topic :: Older Topic >

Pages:<< prev 1 next >>
Post is unread #1 Nov 3, 2006, 8:54 pm
Go to the top of the page
Go to the bottom of the page

Kigen

GroupMembers
Posts38
JoinedNov 3, 2006

Well, after putting the codebase up I got spammed with errors from the areas. Seeing as the intended purpose is to convert it to a DBZ based mud, I saw no reason to keep the areas except Limbo and Help.are, after I removed all the areas, the mud started crashing when I tried to login (getting past the MOTD). I used gdb to find the source.

The bug lies with this section of code. It shouldn't be checking for the structure member "vnum" before it checks to see if the structure is NULL.

   if( !get_room_index( pRoomIndex->vnum ) )
      pRoomIndex = NULL;

   if( !pRoomIndex )
   {
      bug( "%s: %s -> NULL room!  Putting char in limbo (%d)", __FUNCTION__, ch->name, ROOM_VNUM_LIMBO );
      /*
       * 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 );
   }


I fixed it by changing it to this.

   if( !pRoomIndex || !get_room_index( pRoomIndex->vnum ) )
   {
      bug( "%s: %s -> NULL room!  Putting char in limbo (%d)", __FUNCTION__, ch->name, ROOM_VNUM_LIMBO );
      /*
       * 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 );
   }


I would advise who ever put that if check there to think before putting sections of code like that. No offence, but it is just logical to check for a NULL structure before checking for a structure member.
       
Post is unread #2 Nov 3, 2006, 9:31 pm
Go to the top of the page
Go to the bottom of the page

Kigen

GroupMembers
Posts38
JoinedNov 3, 2006

After a headache trying SWR, I decided to use SMAUG FUSS. I went ahead and checked for the bug before I even compiled. It was there.

Samson, think. :P I bet it is in most version of FUSS. So you might wish to check for it.
       
Post is unread #3 Nov 3, 2006, 9:39 pm   Last edited Nov 25, 2007, 6:53 pm by Samson
Go to the top of the page
Go to the bottom of the page

Samson
Black Hand
GroupAdministrators
Posts3,639
JoinedJan 1, 2002

Yes. It was the product of a recent hackish fix to prevent problems with edge cases caused by using rdelete on a room you're standing in.
http://www.smaugmuds.org/index.php?a=topic&t=2307

Your fix to it is actually not going to solve the problem we're trying to solve because the pRoomIndex pointer is still "valid" under the conditions that cause the crash we were trying to fix. Since your fix checks first for pRoomIndex being NULL, and the pointer isn't null, the vnum check is never going to get looked at and the problem will remain. So in effect you're negating the posted fix. There has to be some kind of way to get this to work right without running into what you just did.

This is one of the aspects of C/C++ I really really hate. Deleted pointers dangling in memory that don't point to anything valid.
       
Post is unread #4 Nov 3, 2006, 9:42 pm
Go to the top of the page
Go to the bottom of the page

Kigen

GroupMembers
Posts38
JoinedNov 3, 2006

Doesn't the OR statement fix the problem, it does the same freaking check. It might be true that it doesn't have a NULL pointer, but it does the vnum check afterward.
       
Post is unread #5 Nov 3, 2006, 9:48 pm
Go to the top of the page
Go to the bottom of the page

Kigen

GroupMembers
Posts38
JoinedNov 3, 2006

I just tested my fix on SMAUG FUSS, it works perfectly fine. I was transported to Limbo, and the mud didn't crash.

if( !pRoomIndex || !get_room_index( pRoomIndex->vnum ) )
       
Post is unread #6 Nov 3, 2006, 9:56 pm
Go to the top of the page
Go to the bottom of the page

Samson
Black Hand
GroupAdministrators
Posts3,639
JoinedJan 1, 2002

Oh, right. It's late. Your logic does indeed work. For some reason I must have been thinking you were doing a && instead of ||. Guess I should think about getting some sleep :P
       
Post is unread #7 Nov 4, 2006, 12:12 pm   Last edited Nov 25, 2007, 6:54 pm by Samson
Go to the top of the page
Go to the bottom of the page

Kigen

GroupMembers
Posts38
JoinedNov 3, 2006

Well, I was starting to wonder because I saw nothing that would block that statement. My knowledge in C/C++ comes from my seemingly unnatural logic and comprehension skills.

I figured that its much more logical to do that if statement since you just use NULLing the pRoomIndex data to get the same affect, only thing is that you MUST check to see if the variable passed is not NULL before checking for a structure member, becuase you didn't check if the structure was NULL before checking if the structure "vnum" was valid you caused a crash situation.

You should also update your fix that you linked ([url]http://www.smaugmuds.org/index.php?a=topic&t=2307[/url]) so that other people will not encounter this problem.
       
Post is unread #8 Nov 13, 2006, 3:46 am
Go to the top of the page
Go to the bottom of the page

Moridian

GroupMembers
Posts5
JoinedNov 13, 2006

I'm having the same problem BUT I am planing on keeping the areas.

I've done nothing to the code or areas. Simply compiled, started the mud and logged in and I get spammed with tons of:

Log: [*****] BUG: char_to_room: businessman man human -> NULL room! Putting char in limbo (2)

Messages. Different mobs, but 20 or so at a time. When I check limbo it seems like darn near every mob is in there.

-Moridian
       
Post is unread #9 Nov 13, 2006, 3:05 pm
Go to the top of the page
Go to the bottom of the page

kiasyn
Magician
GroupMembers
Posts121
JoinedJun 30, 2006

check your resets and make sure there are no nasty errors. (aassign area, reset list)
       
Post is unread #10 Nov 18, 2006, 8:47 am
Go to the top of the page
Go to the bottom of the page

Kigen

GroupMembers
Posts38
JoinedNov 3, 2006

Naw, I'm starting to think it has something to do with the new check (vnum) that you added. Though I'm not sure how SWR handles its rooms so I'm no expert. Because I noticed that when I started the mud up I got those errors, but the mud didn't crash, meaning there was a valid pointer, it just didn't have the proper "vnum."
       
Post is unread #11 Nov 18, 2006, 4:58 pm
Go to the top of the page
Go to the bottom of the page

Samson
Black Hand
GroupAdministrators
Posts3,639
JoinedJan 1, 2002

Removing vnums from the game would probably do that if you removed any of the ones required by hardcoded references. That's outside the scope of the fix. Can't code against reckless deletion :)
       
Post is unread #12 Jan 4, 2007, 3:12 am   Last edited Nov 25, 2007, 6:55 pm by Samson
Go to the top of the page
Go to the bottom of the page

Caius
Magician
GroupMembers
Posts132
JoinedJan 29, 2006

This seems to be related to virtual rooms (see here).

It seems get_room_index() doesn't check the virtual room hash table (vroom_hash[]). That is why the mobiles in the coruscant_streets area file are affected, as that's where virtual rooms are used in the SWR distro. Since this glitch haven't been spotted earlier I think we can safely assume very few ever used virtual rooms. I'd love to post the fix, but I'm not very comfortable with the virtual room code. So I'll leave that to someone else.

Edit: Just to clarify: I'm referring to mobs ending up in limbo, and not the original topic as such.
       
Pages:<< prev 1 next >>