Gammon Forum : SMAUG : SMAUG coding : Actflags causing crashes [SWR]

Register forum user name Search FAQ

Gammon Forum

Entire forum

SMAUG

SMAUG coding

Actflags causing crashes [SWR]

Actflags causing crashes [SWR]

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

Pages: 1 2 3

Posted by

Evre (19 posts)

Date

Fri 20 May 2005 06:00 PM (UTC)

Message

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.

Posted by

Zeno USA (2,871 posts)

Date

Reply #1 on Fri 20 May 2005 06:12 PM (UTC)

Message

Try using gdb, it'll help us figure out what's going on. Without it, it's pretty hard to find out.

Zeno McDohl,
Owner of Bleached InuYasha Galaxy
http://www.biyg.org

Posted by

Evre (19 posts)

Date

Reply #2 on Fri 20 May 2005 06:23 PM (UTC)

Message

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

Posted by

Zeno USA (2,871 posts)

Date

Reply #3 on Fri 20 May 2005 06:28 PM (UTC)

Message

Right at the top of the page in Smaug Coding there's a link to the guide.
http://www.gammon.com.au/forum/bbshowpost.php?bbsubject_id=3653

I suggest you learn it, it's really useful. ;)
You are correct though, that's the syntax. It won't do anything to your makefile.

Zeno McDohl,
Owner of Bleached InuYasha Galaxy
http://www.biyg.org

Posted by

Evre (19 posts)

Date

Reply #4 on Fri 20 May 2005 06:34 PM (UTC)

Message

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.

Posted by

Zeno USA (2,871 posts)

Date

Reply #5 on Fri 20 May 2005 06:39 PM (UTC)

Message

You aren't spamming the boards, don't worry. This is better, because if someone has the same issue in the future, they can look here.

If there's no core, you need to enable core dumping. The guide should tell you how, using ulimit.

Zeno McDohl,
Owner of Bleached InuYasha Galaxy
http://www.biyg.org

Posted by

Evre (19 posts)

Date

Reply #6 on Fri 20 May 2005 06:50 PM (UTC)

Message

-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

Posted by

Zeno USA (2,871 posts)

Date

Reply #7 on Fri 20 May 2005 06:54 PM (UTC)

Message

The core should be dumped wherever the process was running. Normally in the area dir. But...

Quote:
core file size (blocks, -c) 0

As you can tell, it's not going to dump a core when the file limit is 0. You have to set that up, as the guide says.

Zeno McDohl,
Owner of Bleached InuYasha Galaxy
http://www.biyg.org

Posted by

Evre (19 posts)

Date

Reply #8 on Fri 20 May 2005 07:10 PM (UTC)

Message

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;

/* static void SegVio()
*{
* CHAR_DATA *ch;
* char buf[MAX_STRING_LENGTH];
*
* log_string( "SEGMENTATION VIOLATION" );
* log_string( lastplayercmd );
* for ( ch = first_char; ch; ch = ch->next )
* {
* sprintf( buf, "%cPC: %-20s room: %d", IS_NPC(ch) ? 'N' : ' ',
* ch->name, ch->in_room->vnum );
* log_string( buf );
* }
* exit(0);
} */

and commenting out the first line the guide mentions as well;

/* signal( SIGSEGV, SegVio ); */

After that I ran a clean compile, hotbooted and made the bug occur again. I'm still not seeing a core file.

Posted by

Zeno USA (2,871 posts)

Date

Reply #9 on Fri 20 May 2005 07:11 PM (UTC)

Message

What OS are you using? If Windows/Cygwin, cores are not dumped. You caused the crash to occur and see no corefile?

The next option is to attach gdb to the process then make it crash.

Zeno McDohl,
Owner of Bleached InuYasha Galaxy
http://www.biyg.org

Posted by

Evre (19 posts)

Date

Reply #10 on Fri 20 May 2005 07:14 PM (UTC)

Message

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

Posted by

Zeno USA (2,871 posts)

Date

Reply #11 on Fri 20 May 2005 07:19 PM (UTC)

Message

Yes, make sure you continue when you run it, then crash it.

Zeno McDohl,
Owner of Bleached InuYasha Galaxy
http://www.biyg.org

Posted by

Evre (19 posts)

Date

Reply #12 on Fri 20 May 2005 07:21 PM (UTC)

Message

Oh wow, now this is interesting...

(gdb) continue
Continuing.

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?

Posted by

Zeno USA (2,871 posts)

Date

Reply #13 on Fri 20 May 2005 07:22 PM (UTC)

Message

Read over the gdb guide. Do a backtrace. Print the locals.

Zeno McDohl,
Owner of Bleached InuYasha Galaxy
http://www.biyg.org

Posted by

Evre (19 posts)

Date

Reply #14 on Fri 20 May 2005 07:33 PM (UTC)

Message

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?

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.

80,706 views.

This is page 1, subject is 3 pages long: 1 2 3

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

Go to topic: Search the forum

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.

Comments to: Gammon Software support
Forum RSS feed ( https://gammon.com.au/rss/forum.xml )