Login
User Name:

Password:



Register
Forgot your password?
Vote for Us!
Development
Nov 28, 2018, 10:10 am
By Keirath
First Immortal
Oct 12, 2018, 12:02 pm
By GatewaySysop
Bug in do_climb( )
Jun 5, 2018, 5:31 pm
By joeyfogas
question on overland code
May 31, 2018, 10:03 am
By joeyfogas
KaVir's Protocol Snip
May 15, 2018, 7:57 pm
By joeyfogas
tintin++ ogg sound player script for linux
Author: Robert Smith
Submitted by: Vladaar
6Dragons ogg Soundpack
Author: Vladaar
Submitted by: Vladaar
6Dragons 4.4
Author: Vladaar
Submitted by: Vladaar
LoP 1.46
Author: Remcon
Submitted by: Remcon
LOP 1.45
Author: Remcon
Submitted by: Remcon
Users Online
CommonCrawl, Bing, DotBot

Members: 0
Guests: 13
Stats
Files
Topics
Posts
Members
Newest Member
481
3,740
19,397
640
KieraZajac
Today's Birthdays
There are no member birthdays today.
Related Links
» SmaugMuds.org » General » Smaug Snippets » Hotboot declaration error
Forum Rules | Mark all | Recent Posts

Hotboot declaration error
< Newer Topic :: Older Topic > Room_index_hash in function `save_w

Pages:<< prev 1 next >>
Post is unread #1 Mar 7, 2003, 9:16 am
Go to the top of the page
Go to the bottom of the page

Artex

GroupMembers
Posts4
JoinedMar 7, 2003

Greetings
I have recently tried to implement the hotboot snippet to my little Smaug 1.4a "package" I'm making for myself, but I encountered an error during the compilation that didn't want to be resolved easily. I'm not a good C coder, so I couldn't really find any suitable solution to that problem.

=== Compiler Message ===
hotboot.c: In function `save_world':
hotboot.c:138: `room_index_hash' undeclared (first use in this function)
hotboot.c:138: (Each undeclared identifier is reported only once
hotboot.c:138: for each function it appears in.)
=== Line Content ===
for( pRoomIndex = room_index_hash[iHash]; pRoomIndex; pRoomIndex = pRoomIndex->next )

I tried adding "ROOM_INDEX_DATA **room_index_hash;" and it DID let me through the compile process, but the command itself didn't work (SegFault), so I presume that this isn't the right way to declare this variable.
If anyone can give me an advice or a possible solution to this I will gladly appreciate (or how the word is spelled) it.
P.S. I'm running the MUD on RedHat 8.0 - kernel 2.4.18-14.
       
Post is unread #2 Mar 7, 2003, 12:23 pm
Go to the top of the page
Go to the bottom of the page

Guest - (Unregistered)

Greetings
=== Compiler Message ===
hotboot.c: In function `save_world':
hotboot.c:138: `room_index_hash' undeclared (first use in this function)
hotboot.c:138: (Each undeclared identifier is reported only once
hotboot.c:138: for each function it appears in.)
=== Line Content ===
for( pRoomIndex = room_index_hash[iHash]; pRoomIndex; pRoomIndex = pRoomIndex->next )
I tried adding "ROOM_INDEX_DATA **room_index_hash;" and it DID let me through the compile process, but the command itself didn't work (SegFault), so I presume that this isn't the right way to declare this variable.
If anyone can give me an advice or a possible solution to this I will gladly appreciate (or how the word is spelled) it.
P.S. I'm running the MUD on RedHat 8.0 - kernel 2.4.18-14.

It segfaulted as you created a new local instance for it to work with, rather than using the one already in existance elsewhere, it prolly wasn't init'ed and thus pointing at a random location in memory and thus when trying to dereferance, it blew up

What you need to do is find the orginal decleration (not being a Smaug person I dunno exactly where, historically these things are kept in db.c or comm.c but who knows ) and copy the decleration into the top of hotboot.c and put "extern" on the front. For example, where you'd have

ROOM_INDEX_DATA **room_index_hash;

in db.c/comm.c or where ever it is, in the top of hotboot.c you need the line

extern ROOM_INDEX_DATA **room_index_hash;

The extern keyword informs the compiler that the actual variable is external to the local file, so when compiling down the object file slap it into the symbol table and worry about resolution/access to that symbol later on (usually at link when it brings all the objects together).
       
Post is unread #3 Mar 7, 2003, 1:01 pm
Go to the top of the page
Go to the bottom of the page

Artex

GroupMembers
Posts4
JoinedMar 7, 2003

Thanks for pointing me at db.c where I bumped into a real declaration of room_index_hash which is:

ROOM_INDEX_DATA * room_index_hash [MAX_KEY_HASH];

Although, fixing the variable didn't really solve the SegFault problem for some reason. The last thing I saw in the logs was the "Preserving world state...." message...
I will go play with it now by placing a lot of log messages to get more specific source of the problem and, perhaps, try to solve it.

If someone has passed through that kind of trouble before and managed to fix it, you're welcome to share your ways with me ;)

Thanks for your help, again, Trax
       
Post is unread #4 Mar 7, 2003, 1:35 pm
Go to the top of the page
Go to the bottom of the page

Guest - (Unregistered)

Thanks for pointing me at db.c where I bumped into a real declaration of room_index_hash which is:
ROOM_INDEX_DATA * room_index_hash [MAX_KEY_HASH];
Although, fixing the variable didn't really solve the SegFault problem for some reason. The last thing I saw in the logs was the "Preserving world state...." message...

Odd... externing it should have made it work, unless the hash itself is damaged in some way during construction, the fact its dying on "Preserving World State" which implies its going through everything and saving something to do with each room (persistant world ata I guess) means its hitting everything in the hash.

Logging can help, also run it inside gdb if you can ("cd areas; gdb ../path/to/executable ; run portnum" or similar to kick it off, sorry I dunno if you know gdb at all, thought I'd include it just to be sure) and it'll dump you at the crash point and you can at least print the variables and see what state they are in and at which point in the hash it did die and why that part of the hash is bad. The Gdb run is only worth doing if you can repeat it though, otherwise you could be sitting there for a while waiting for the right circumstances.
       
Post is unread #5 Mar 7, 2003, 1:57 pm
Go to the top of the page
Go to the bottom of the page

Artex

GroupMembers
Posts4
JoinedMar 7, 2003

(This post is accidental! Please disregard it or remove it if you can. Sorry)
       
Post is unread #6 Mar 7, 2003, 2:11 pm
Go to the top of the page
Go to the bottom of the page

Artex

GroupMembers
Posts4
JoinedMar 7, 2003

Well.. Doing log-"zooms" and GDB lead me to `fwrite_obj` function in save.c and specifically to the following IF statement:

if ( obj->prev_content && os_type != OS_CORPSE )
fwrite_obj( ch, obj->prev_content, fp, iNest, OS_CARRY, hotboot );

The output GDB gave me is:

Program received signal SIGSEGV, Segmentation fault.
0x080fc5c8 in fwrite_obj (ch=0x0, obj=0x203f6e, fp=0x84fa030, iNest=0, os_type=0, hotboot=1 '01')
at save.c:568
568 if ( obj->prev_content && os_type != OS_CORPSE )

Could be something with one of the three pointers, it seems, but with my C knowledge it's going to be even more painful to try and fix this. I'll go through the code tomorrow and, at least, disable the command if it won't resolve. It's not my top priority at this time
Thanks again and good night ;)

P.S. Sorry for the previous post! My browsers fault >.<
       
Pages:<< prev 1 next >>