Firstly, forgive me if this is improperly placed, written, or otherwise offensive to the general workings of this forum. I've looked through the earlier threads here, but I haven't found any pertaining to my problem, so in hopes of getting some help from you gracious folk, I'll post it here.
For the purposes of my MUD concept, I've found that the SWR codebase works very well for my needs, and the fact that I know it fairly well as a player only adds to its usefulness. While I might not be running a Star Wars based MUD theme, the scifi game elements add to it and I'll need to do only mostly cosmetic changes to have the server fit. Off the top of my head, I've changed a few race and language names, modified the hunger and thirst code to ignore any player above level 0, added in a few well-known SWR code snippets (The frequency snippet, Clanstat, etc.), deleted most of the non-code-dependant areas, changed the maximum line input from 249 to 999, and changed a few text strings to get away from the Star Wars theme.
Having attended most of the undercoding, I moved on to the building aspect. Again, everything fit smoothly together and I created a decent-sized starting area to run some testing in. Then came the MOBs... again, everything was fine with their stats, names, and MPrograms. It came time to install the area, so I did, and in doing so removed the prototype flags from everything. So I went back and tried to set the SENTINEL Actflag on a mob named 'Secretary' (wouldn't want her wandering around, afterall). A few seconds pass after I send the command (mset secretary flag sentinel) and all of a sudden the server disconnects me (which I assume implies a server crash). After about half a minute it stops refusing my connection and lets me back on, although the secretary's still wandering about, ignoring her clerical duties. I try setting her to prototype, THEN adding SENTINEL, same thing. AGGRESSIVE crashes the server as well. I haven't toyed with any of the flag coding (or anything closely tied in to it that I know of), so I fail to see what's going wrong. I'm running SWR11Fuss (At least that's the name of the TGZ the source came from).
Anyone else have this problem? Help would be appreciated.
Lovely... that's ah... a little bit advanced for me. I don't want to turn this into another "Let's help the newbie figure out how to use a basic debugger" thread, but... what exactly are my arguments for the object and core files? I would assume something like "gdb ../src/SWReality [corefile]"... Or I could just be entirely lost. I don't even want to think about fudging with my make file...
Yeah, I'm looking at the guide now, that's how I picked out what little syntax I could... but I still don't know where to find the core file. I tried the LS command, but there are apparently no core files present, so without that I can't really get any debug information. Don't suppose you'd like to take this into a messenger? AIM or something? Don't want to spam up the boards too much with GDB issues.
-sh-2.05b$ ls
area/ boards/ building/ color/ councils/ doc/ hotboot/ imc/ mudprogs/ planets/ space/ swr11fuss.tgz tmp/
backup/ Bugfixes.txt clans/ corpses/ deleted/ gods/ i3/ log/ nohup.out player/ src/ system/
-sh-2.05b$ ulimit -a
core file size (blocks, -c) 0
data seg size (kbytes, -d) unlimited
file size (blocks, -f) unlimited
max locked memory (kbytes, -l) unlimited
max memory size (kbytes, -m) unlimited
open files (-n) 1024
pipe size (512 bytes, -p) 8
stack size (kbytes, -s) 8192
cpu time (seconds, -t) unlimited
max user processes (-u) 1791
virtual memory (kbytes, -v) unlimited
-sh-2.05b$ ps -aux
USER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND
evre 6883 0.0 1.0 4000 2248 ? T 18:49 0:00 ../src/swreality 7431
evre 7932 0.0 0.3 2400 852 pts/9 R+ 19:36 0:00 ps -aux
-sh-2.05b$
-sh-2.05b$ ls -lt core*
ls: core*: No such file or directory
So from what I gather, Ulimit isn't much use considering it's already set to unlimited. I tried finding the core file with the suggested command, but obviously that didn't work either. I'm quite literally at my wit's end here. There's no core file to use, and even if there were I doubt I have the foreknowledge to use this damnable GDB thing to figure out the source of the crashes. But, one step at a time, I suppose. Ulimit's set to unlimited, so what's next? The guide mentions something about modifying my make file to enable compile debuging, but I'm not going to touch the thing. I really don't want to screw it up. o.o
Wonderful, I can't even read now, apparently. Mixed up the unlimited values on the right, so it looked alright to me on Putty. Alright, core file size is set, and I ran a clean/make but I'm still lacking a core file. Apparently I need to comment out some code in comm.c so I'm changing the SegVio() code to;
Using GCC as the compiler I suppose. The MUD's hosted remotely on a friend's server, and I'm connecting via SSH (Putty).
-sh-2.05b$ gdb swreality
GNU gdb 6.2-2mdk (Mandrakelinux)
Copyright 2004 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB. Type "show warranty" for details.
This GDB was configured as "i586-mandrake-linux-gnu"...Using host libthread_db library "/lib/tls/libthread_db.so.1".
So that implies that GDB is now attached the proecess, correct? I'll try the crash again...
Program received signal SIGSEGV, Segmentation fault.
0x0815cf30 in drunk_randoms (ch=0x82ae150) at update.c:2020
2020 if( IS_NPC( ch ) || ch->pcdata->condition[COND_DRUNK] <= 0 )
(gdb)
I went through and changed a lot of the if checks to negate the thirst/hunger system, but I didn't touch the drunkenness code. So the problem lies somewhere in there?
I realize how frustrating this must be for you - "The guide is /right/ there, newbie... /read/ it." RTFM and all that... but it doesn't do me much good if I don't grasp it. So here's what I can gather from the thing so far...
(gdb) frame
#0 0x0815cf30 in drunk_randoms (ch=0x82ae150) at update.c:2020
2020 if( IS_NPC( ch ) || ch->pcdata->condition[COND_DRUNK] <= 0 )
(gdb) list
2015 CHAR_DATA *rvch = NULL;
2016 CHAR_DATA *vch;
2017 short drunk;
2018 short position;
2019
2020 if( IS_NPC( ch ) || ch->pcdata->condition[COND_DRUNK] <= 0 )
2021 return;
2022
2023 if( number_percent( ) < 30 )
2024 return;
(gdb) i args
ch = (CHAR_DATA *) 0x82ae150
(gdb) i locals
rvch = (CHAR_DATA *) 0x0
vch = (CHAR_DATA *) 0x8280c78
drunk = 2088
position = 2632
(gdb) bt
#0 0x0815cf30 in drunk_randoms (ch=0x82ae150) at update.c:2020
#1 0x08159820 in mobile_update () at update.c:781
#2 0x0815d65c in update_handler () at update.c:2241
#3 0x080a2d21 in game_loop () at comm.c:569
#4 0x080a234a in main (argc=2, argv=0xbffff7f4) at comm.c:261
Unfortunately this means little to me. I can do a print *ch and get about 3 pages worth of variables, but I know that the problem lies in the flags, I just don't know /why/ the flags are screwing everything up. That drunkenness thing, is that part of the problem or was it just the last thing to be looped before the crash?
That'd be my mob (NPC) I'm setting the SENTINEL flag to.
If you need a client-side view of the crash...
Research Facility Kierkeguard - Entryway {2001[indoors]
The room expands just slightly from the Foyer to the south, the two divided
by a thick metal border inlaid around the rooms' edges. Soft lighting and
light blue walls give off a sense of serenity, while the cold metal
accents and furnishings keep a business-like touch in the air.
A polished mahogany desk rests in the center of the room. Two computers and
a stack of papers lie atop its reflective surface.
Obvious exits:
North - (closed)
South - Research Facility Kierkeguard - Foyer
A secretary sits at a computer here.
(Blue Aura) A security guard stands watch here.
A secretary says 'Welcome to the facility.'
Can you show me the IS_NPC macro? Should be in mud.h
It should return before the drunk check, so that should be fine. I'm not sure what's going on, but I'm going to suggest changing back the changes you made to the hunger/thirst code.
That's the only bit of code that defines IS_NPC, any other search results just turn up lines that use it in mud.h. I hate to put the bloody thirst/hunger system in again. Suppose I'll have to find another way around it.
Ah, I realize the problem, perhaps. Yes, it is flags it seems, not your change. Since its checking act flags, it's the flags that crashed as you said. Have you made any changes to the act flags in the code at all? This is not a normal SWR crash.
No, I haven't intenionally changed any of the flag codes (that's far too over my head), and none of the snippets I installed made any changes to them... oddness. o.O
Hm, can you show the act flag struct (in mud.h) and the const struct in build.c here? Has this problem always happened? If not, when did it happen, after a certain change?
I think if it is an NPC the conditional will stop with IS_NPC, but in case it doesnt you are probably pointing to data that doesnt exist. This'll crash your program quite easily. No data == bad.
Not sure if its the source of the crash, but its definitely something to be aware of. You could change it like so:
Both sets of code came stock with the distrobution of source I'm using and haven't been changed (by myself, anyway, and I'm the only person toying with the source at the moment... Hell, I'm the only person connecting to my server at the moment). Same thing goes with the code Whiteknight was concerned with, though I recognize the potential bug and enacted his suggested changes anyway. Didn't fix the ACTFLAG problem, but I didn't expect it to.
I don't believe I've thanked any of you for being so patient and imparting so much advice and help. You've a great deal of gratitude from me.
I don't seem anything wrong there. The only thing I can suggest now is to go back through each change and test the crash. If it doesn't crash, then you know that the latest change you reverted was the issue.
Ah... that's happy news. The one time I get lazy and neglect to comment my changes it bites me in the rear... A lesson hard learned, I suppose.
If I recall correctly, the last change I made was to the hunger and thirst code - with the ifchecks that determine what effects to place on the player should they become too hungry or thirsty, they had a check that ignored anyone that had level = IS_AVATAR or something to that effect, so I think I changed it to apply to anyone whose level was under 1. It didn't seem like the best idea, but it did sound like the quickest way to rid myself of that horrid system.
Just an off the wall idea here. Are you certain the flags you intend to change are the ones being changed? Maybe it's changing the NPC flag instead, which I'm sure would cuase problems if you lifted it from an NPC. :-o
Just an idea. It would explain why it crashes on the line that checks for NPC status and then checks the con_drunk stuff. If it doesn't think it's an NPC it'll blow right past and attempt to check data that the mob does not have, which would probably cause the crash.
I'm not certain what you're asking here so I'll just detail the problem in hopes that it'll answer your question;
Using mostly Stock SWR code (The flag coding hadn't been changed), I attempt to set a sentinel flag (aggressive does it as well, haven't tried the rest) on a self-made mob (mcreate secretary etc etc) using mset secretary flags SENTINEL, which causes the crash. The mob is one of my own making, and upon an mstat, it shows that it has the IS_NPC flag. As far as the flag code itself goes as far as checking for NPC data that isn't there, I don't see why it would if I haven't changed it from stock?
What I was asking is exactly what was said. Namely, are you certain the flags you're trying to change are the ones being changed? Maybe if something is off, you're telling it to apply the sentinel flag but really it's adding/removing a different flag altogether. Have you tried settings flags that work and using MSTAT to see if the correct flag has been added/removed from the mob?
Also have you tried digging up a backup from before any recent changes to see if you can replicate this behavior? If not then you can be certain it was something you changed and it's only a matter of back tracking.
If you can do this even with a stock copy of the distribution, that would be of even more interest, because it would indicate that there's probably a bug of some kind.
Anyway, more information is always useful so please post again with what you've found out.
Still in the process of figuring out exactly what's going on, but I thought I'd go ahead and share some newer issues. Apparently when I set the PROTOTYPE flag, several flags are set (As I suppose they're supposed to be) - Among them are "sentinel" "scavenger" "r3" and "r3" (it displays twice). The R3 flag is just a placeholder isn't it?
Well, I've tried most of the flags and only prototype neglects to cause a crash. Another curious thing is that after I set the prototype flag on an NPC, I set him to AGGRESSIVE as well. This is what I got;
vnum:<#2000> / wizinvis: 0
look
Research Facility Kierkeguard - Foyer {2000[indoors]
The cool, calm ambience of the room accents its mixture of lavish oak and steel furnishings. The room itself is of fair size for a foyer. Paintings of pleasant landscapes dot the light blue walls, perforated with simple half-oval light fixtures that give off a soft white glow toward the smooth white ceiling.
Obvious exits:
North - Research Facility Kierkeguard - Entryway
(Link Dead) (Blue Aura) A security guard stands watch here.
He went /link dead/. o.O A few moments after that the MUD crashed, which is strange as well because there was a delay this time. Is this common behavior for NPCs? And, on that same token, what exactly does the blue aura imply? I had assumed prototype but when I checked my secretary, who doesn't have the prototype flag, she's got a blue aura as well.
- EDIT -
Rather than double post, I'll just add on to what I've already posted... The bug's been there for as long as I can recall, actually, though I don't have any backups dating back before I first starting changing text strings, but I do recall that a few days after I first got the MUD running I logged on and tried to show a friend how to create a "monster" but the MUD kept crashing. I didn't realize it at the time but it was because I was setting the AGGRESSIVE flag.
I tried changing the thirst/hunger code back to normal, but the bug persists. Lacking any other option, I'm going to go through and post anything relevant to flag setting -
In build.c
if( IS_NPC( victim ) )
{
value = get_actflag( arg3 );
if( value < 0 || value >= 31 )
ch_printf( ch, "Unknown flag: %s\n\r", arg3 );
else if( 1 << value == ACT_PROTOTYPE && ch->top_level < sysdata.level_modify_proto )
send_to_char( "You cannot change the prototype flag.\n\r", ch );
else if( 1 << value == ACT_IS_NPC )
send_to_char( "If the NPC flag could be changed, it would cause many problems.\n\r", ch );
else
TOGGLE_BIT( victim->act, value );
}
else
{
value = get_plrflag( arg3 );
if( value < 0 || value >= 31 )
ch_printf( ch, "Unknown flag: %s\n\r", arg3 );
else if( 1 << value == ACT_IS_NPC )
send_to_char( "If the NPC flag could be changed, it would cause many problems.\n\r", ch );
else
{
ftoggle = TRUE;
TOGGLE_BIT( victim->act, value );
}
}
}
if( ftoggle )
send_to_char( "Flags set.\n\r", ch );
if( IS_SET( victim->act, ACT_PROTOTYPE ) || ( value == ACT_PROTOTYPE && protoflag ) )
victim->pIndexData->act = victim->act;
return;
(ACT flag structure from mud.h is posted earlier in this thread so I won't bother reposting it.)
That's all the relevant code I can think to find at the moment. If I'm spamming with too much of this stuff or if I'm not heading in the right direction, don't hesitate to tell me. Thanks.
You just said *exactly* what I was asking you to check for, whether or not you realize it. I quote you:
Quote:
Apparently when I set the PROTOTYPE flag, several flags are set (As I suppose they're supposed to be) - Among them are "sentinel" "scavenger" "r3" and "r3" (it displays twice).
This is, almost without a doubt, your problem. Obviously you're setting more flags than you want to be, and quite possibly you're un-setting flags that you shouldn't be in the process. When you set the prototype flag, that should be the only one that changes. That's how it's SUPPOSED to work. You should never have multiple flags setting themselves/unsetting themselves after you MSET a particular single flag on something/someone.
You need to figure out what it was you changed that caused this problem, because it is almost assuredly the root cause of your crashes.
Beyond that, and as I said earlier, having a crash when it tries to read pcdata from a mob, and having it crash because a mob goes linkdead (should never happen), that seems like an obvious indication that somehow your NPC flag is being stripped or something. The fact that you have flags being set/unset like this when you never toggled them in the first place lends strong credence to this possibility.
It is quite useful, however I'm running into trouble trying to isolate the exact source of the issue. Do you possibly know how the flags are set/toggled? I've only found two areas where the code is defined and that's in build.c and mud.h (And mud.h simply defines). GREP just turns up a bunch of build.c references, but when I look in there I fail to see anything obviously wrong. You've all helped me a great deal and it's doubtful I would've been able to narrow it down so far without the direction given here.
You mentioned somewhere back about something to do with changing text strings? It's a longshot, but not knowing what you did at all, I would say that may be something to look at.
Beyond that, all I can say is try any backups you have and see how far back you can reproduce the problem. When you hit a wall and it stops happening, you should know exactly what you did and hopefully you'll be able to fix it without having to completely revert to stock.
In all honesty, there's probably a simple explanation for all this, no doubt a single change somewhere that went awry. It shouldn't be all that hard to fix once you narrow it down.
I don't suppose you (or anyone else reading this) knows what "flow" the data takes when setting a flag? Like... it hits the handler... handler references to the mud.h code... and from there it goes to the build.c code. I realize this isn't exactly how it works, but there's a course the data takes via stacks and whatnot (that's what I gather from reading through GDB's backtraces, anyway). So any advice on how to trace through the MSET code would be greatly appreciated. (I've already checked the do_mset in build.c to no avail.)
This line of code,
else
TOGGLE_BIT( victim->act, value );
is actually the bit that /sets/ the flag, isn't it? So would that imply an issue with the way TOGGLE_BIT is set up? I'm pretty well lost at this point so I'm trying to get any help I can.
Maybe what would be of interest is whether or not "value" is somehow different from what it should be.
Like I said, try going back through any backups you have until you can no longer reproduce the problem. That should give you at least a rough idea of what change introduced this so you'll know more specifically about what the issue may be.
What exactly did you change to do with text strings, by the way? I don't know that that has anything to do with this, but it could so that information might be useful.
Unfortunately, all of my backups have the bug, I just hadn't noticed it until recently, so that's out of the question. I'll run GDB and see if I can't grab the value of "value".
I looked through the forums earlier for some tips on changing the languages, classes, and races. I changed all instances of WOOKIEE to TEST_SUBJECT or SHADOW depending on whether or not it was a race or language reference (The names are placeholders at this point, so excuse their foolishness). When I said "Text Strings" I meant I changed messages sent to the players like "You feel a disturbance in the force" would be changed to "You feel something is amiss" - things like that.
All of your backups have this bug? How far back do they go then? Do you only have backups to a point or do you have them all the way back to the stock code?
More imporantly, can you reproduce this in un-touched, stock code? If so that would be of prime interest to whoever maintains the particular SWR codebase that you're using because it may be an actual bug.
If not, that is if you cannot reproduce this in a freshly downloaded copy of the codebase, you definitely introduced the problem with something you did.
I don't know SWR, don't use it, but I'm still gambling that you somehow and most unintentionally introduced this with a change you made. Been there, done that, several times in fact. It happens.
So in short, please check if you can reproduce this with a stock version of the codebase you are using. That's probably the best place to start if all your backups have this issue.
Wish I had better advice but I think we need to know for sure if this was a stock issue or something you introduced.
Took another really close look at this, and compared it to a non-FUSS SWR package and I think the fault may well lie with me on this one :)
The fault lies in build.c in the flags section where the TOGGLE_BIT calls are made. As they are posted in the bad code, they are:
TOGGLE_BIT( victim->act, value );
They need to be:
TOGGLE_BIT( victim->act, 1 << value );
Taking note of the 1 with the 2 less-than signs before the value. That makes all the difference. Toggling the value directly is why it's changing seemingly unrelated bits. Toggling with the added part, it only affects the flag you tried to change.
This is a direct result of one of the SMAUG FUSS fixes being ported across to SWR/SWFOTE improperly. The issue it intended to address was fixed but this bug was introduced by accident.
That did the trick. Flags are setting properly now! Again, thanks to everyone who helped me with the problem. I pray I didn't try your patience /too/ much.
For those who need to perform the bugfix as well, the erroneous instance appears twice, the first one starting near line 1939 in my build.c (Under do_mset), and the second one underneath the next parent else statement a few lines down.
With that bug out of the way, I can get the project back on track! Yay!