Login
User Name:

Password:



Register
Forgot your password?
Vote for Us!
parse description bug
Dec 15, 2017, 10:08 pm
By Remcon
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
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, Yahoo!, Bing, DotBot

Members: 0
Guests: 10
Stats
Files
Topics
Posts
Members
Newest Member
477
3,706
19,240
608
LAntorcha
Today's Birthdays
There are no member birthdays today.
Related Links
» SmaugMuds.org » Codebases » SWR FUSS » SWR1FUSS 2 Billion Vnum snipp...
Forum Rules | Mark all | Recent Posts

SWR1FUSS 2 Billion Vnum snippet
< Newer Topic :: Older Topic > Crashes from memory

Pages:<< prev 1 next >>
Post is unread #1 Mar 28, 2005, 12:53 am
Go to the top of the page
Go to the bottom of the page

Greven
Magician
GroupMembers
Posts204
JoinedMar 5, 2005

There have been a few questions about the 2 Billion VNUM patch and the SWR1FUSS code on the SWR mailing list. I've just installed it on fuss and have been doing some testing. As is standard, it will crash unexpectedly. It only happens if the coruscant streets file is currently running, since this is the only stock area that uses exdist, and there in lies the problem. Its fairly well known that the issue is with virtual rooms, so I've been trying to track it down. I first tested as a control, unmodified, works fine, ran for days. I then installed the snippet, nothing else running, and it crashed in about 5 minutes. I then ran it through Valgrind, and got some information there. I got several different calls similiar to this:
==1808== Invalid read of size 4
==1808==    at 0x8127E57: rprog_enter_trigger (mud_prog.c:2711)
==1808==    by 0x808B3C0: move_char (act_move.c:1142)
==1808==    by 0x81873C7: mobile_update (update.c:949)
==1808==    by 0x818A8E0: update_handler (update.c:2241)
==1808==    by 0x80CF742: game_loop (comm.c:569)
==1808==    by 0x80CED48: main (comm.c:261)
==1808==  Address 0x1BF6DEDC is 84 bytes inside a block of size 124 free'd
==1808==    at 0x1B905460: free (vg_replace_malloc.c:153)
==1808==    by 0x8089556: clear_vrooms (act_move.c:364)
==1808==    by 0x818A9A3: update_handler (update.c:2278)
==1808==    by 0x80CF742: game_loop (comm.c:569)
==1808==    by 0x80CED48: main (comm.c:261)
All of them had the call to clear_vrooms in it. I checked the line, and its where the unused room is disposed. So, that gives me info on where a possible cause, but nothing there seems particularly out of line. So next, I got to gdb. Simple run through, and it crashes as such
Program received signal SIGSEGV, Segmentation fault.
0x081870d2 in mobile_update () at update.c:884
884           if( ch->in_room->area->nplayer > 0 )
(gdb) print *room
No symbol "room" in current context.
(gdb) print ch
$72 = (CHAR_DATA *) 0x84d3290
(gdb) print ch->in_room
$73 = (ROOM_INDEX_DATA *) 0x85d4348
(gdb) print *ch->in_room
$74 = {next = 0x85c98b0, next_sort = 0x2460001, first_person = 0x6e6f6c41, last_person = 0x68742067, 
  first_content = 0x64652065, last_content = 0x6f206567, first_extradesc = 0x68742066, last_extradesc = 0x74732065, 
  area = 0x74656572, first_exit = 0x69617220, last_exit = 0x676e696c, first_ship = 0x72702073, last_ship = 0x6e657665, 
  name = 0x65702074 <Address 0x65702074 out of bounds>, description = 0x74736564 <Address 0x74736564 out of bounds>, 
  vnum = 1851877746, room_flags = 1919295603, mpact = 0x66206d6f, mpactnum = 1768713313, mudprogs = 0x7420676e, 
  mpscriptpos = 3439, progtypes = 1919509864, light = 25632, sector_type = 24933, tele_vnum = 539912308, 
  tele_delay = 21536, tunnel = 28535, first_reset = 0x6f657020, last_reset = 0x20656c70, last_mob_reset = 0x7261656e, 
  last_obj_reset = 0x73207962, next_aroom = 0x74756f68, prev_aroom = 0x61656820}
(gdb) print *ch->in_room->area
Cannot access memory at address 0x74656572
So, now we have the fact that the room is corrupt, and a likely place for corruption, however nothing sticks out immediately. My only thought is that there still exists a pointer to this room in a ch->in_room, but thats fairly safely checked by the !room->first_char. I'm a little tired at the moment, if anyone has any suggestions, or actually knows the solution, I would be muchly appreciated.
       
Post is unread #2 Mar 28, 2005, 3:15 am
Go to the top of the page
Go to the bottom of the page

Samson
Black Hand
GroupAdministrators
Posts3,639
JoinedJan 1, 2002

Have you thoroughly checked the code to be sure there are no unsafe usages of ch->in_room? Such as changing the room to a new one without updating the old one? I had some similar problems with a piece of rogue code where char_from_room and char_to_room had not been used to move the person/mob from place to place and it would cause similar random corruption like this.

Then again, what you're getting now looks an awful lot like some of the recent crashes I've been getting. I wonder if one of the Smaug fixes might have contributed something to this. I had thought up to this point that what I had was because of some biffed C++ conversions.
       
Post is unread #3 Mar 28, 2005, 3:38 pm
Go to the top of the page
Go to the bottom of the page

Greven
Magician
GroupMembers
Posts204
JoinedMar 5, 2005

I thought about a bad room change, but I didn't change any calls to anything even close to room changes, and this is installed on stock SWR:FUSS and since no one else has come up with it, and it only happened after I put in this code, I have to assume that its something specific to the 2 bill code. I tried running the unmodified SWR:FUSS through valgrind as well, just to ensure these same issue are not present, and they aren't. Now, after checking through the code and a little testing, I did notice that all of the virtual vnums were around 20,000,000. This could very easily have conflicts with real rooms with the same vnum numbers, but at this point its not since those rooms don't exist. Something else I'll have to look into I guess.
       
Post is unread #4 Mar 29, 2005, 2:24 pm
Go to the top of the page
Go to the bottom of the page

Odis

GroupMembers
Posts46
JoinedMar 8, 2005

If you think this may be related to one of the FUSS fixes (like Samson was wondering), you could try testing it on a nonfuss unmodified SWR 1.0 release and see how it goes. Though I doubt it has anything to do with the fixes, this would be a good way to check.

I myself have never installed the snippet, as i did things the lazy and unefficient way. Perhaps I'll try the snippet and help you out with this when school dies down a bit (end of the quarter this week).
       
Post is unread #5 Mar 29, 2005, 11:43 pm
Go to the top of the page
Go to the bottom of the page

Greven
Magician
GroupMembers
Posts204
JoinedMar 5, 2005

Yeah, the same thing happens on stock SWR1.0 as well, so it's not FUSS related. I've been looking, but this starting to get annoying...
       
Post is unread #6 Mar 30, 2005, 4:47 am
Go to the top of the page
Go to the bottom of the page

Samson
Black Hand
GroupAdministrators
Posts3,639
JoinedJan 1, 2002

Realized I forgot to ask, but where was the 2 billion vnum patch acquired from?

Also, not sure if you were aware, but vnums should have already been fixed to be full ints instead of shorts. It was classified early on as one of the bugs that was fixed since most of the code that dealt with vnums was expecting full int, even in the structs. Only one of the mob vnum sets was still flagged as a short at the time.
       
Post is unread #7 Mar 30, 2005, 9:16 am   Last edited Nov 25, 2007, 6:59 pm by Samson
Go to the top of the page
Go to the bottom of the page

Greven
Magician
GroupMembers
Posts204
JoinedMar 5, 2005

Its the one off of smaugmuds.org under the Sadiq(?) section I beleive. And while installing it, a good portion of the integers were converted already, made the job a lot easier, but there were still thinkgs like hard coded 32767 and 32766 reference which
needed to be replaced with the pre-define in mud.h. When I get some time today, I'm going to try lowering the limit for the define to about 10 milion and see if it makes a difference, since there is no chance of it conflicting.
       
Post is unread #8 Mar 30, 2005, 5:34 pm
Go to the top of the page
Go to the bottom of the page

Samson
Black Hand
GroupAdministrators
Posts3,639
JoinedJan 1, 2002

It might almost be worth going over all this and counting it as another bugfix considering other people may try to apply the same patch and run into the same issues. Then again, if it's not a problem with the patch, I'm not sure what it might be. I took the virtual room code out of my base completely long ago.
       
Post is unread #9 Mar 30, 2005, 9:30 pm
Go to the top of the page
Go to the bottom of the page

Greven
Magician
GroupMembers
Posts204
JoinedMar 5, 2005

I've reduced the size of MAX_VNUM to 10000000, and no crash, no complaint from valgrind, so its something with conflicts, I think... or perhaps the size of the hash, I'll have to check that.
       
Pages:<< prev 1 next >>