This forum is a read-only archive of the Gammon Software forum (2000–2026). No new posts can be made. Search the archive.

Swfote core dump move to room with another player

Posted by MattJ820 on Sun 05 Apr 2015 06:20 PM — 17 posts, 66,176 views.

MattJ820 #0
Hello,

I'm having my core dump whenever I move to a room with another character. I made a test character to test new features I coded but if i use goto to transfer to him, the mud crashes, if I transfer him to me it crashes, if I goto the room next to him and then manually move into his room, it crashes.

I used lldb on OSX to look at the core file and it gave me this out of comm.c. Anyone know how to fix this? I'm using swfote2.1.5

(lldb) target create "../bin/swr"
Current executable set to '../bin/swr' (x86_64).
(lldb) settings set -- target.run-args "core.15758"
(lldb) list
152 {
153 struct timeval now_time;
154 bool fCopyOver = !TRUE;
155
156 /*
157 * Memory debugging if needed.
158 */
159 #if defined(MALLOC_DEBUG)
160 malloc_debug( 2 );
161 #endif
Amended on Sun 05 Apr 2015 06:25 PM by MattJ820
Nick Gammon Australia Forum Administrator #1
See my page about gdb: http://www.gammon.com.au/gdb

I would at the very least be typing "bt" to do a backtrace. Find which line it is crashing on. Maybe there is a NULL pointer.
MattJ820 #2
Hey Nick,

I read your guide. I launched the mud from within lldb and caused the core dump so I could run the steps. bt is not showing as a valid process even though it's listed in the help file. Do you know if I'm doing this right?

Sun Apr 5 17:54:09 2015 :: Reading in area files...
Process 17017 exited with status = 1 (0x00000001)
(lldb) Abort (core dumped)
bt
error: invalid thread
(lldb) backtrace
error: 'backtrace' is not a valid command.
(lldb) bt
error: invalid thread
(lldb) bt 17017
error: invalid thread
(lldb)
Nick Gammon Australia Forum Administrator #3
In your first post you seemed to have lldb working, in your more recent one, not.

Can you post everything from when you start up the MUD? Not just the last few lines.
MattJ820 #4
This is the snapshot I get when I run the mud in lldb. The core dump was caused by "at look Test' or goto Test or moving into the same room as Test. Test is a mortal I made to try out new skill code.

Still do not understand why I can't do a BT. I'm definitely in the debugger tool.. list works and so do a few other commands that are in the help file.

(lldb) run
Process 19224 launched: '../bin/swr' (x86_64)
Mon Apr 6 18:38:54 2015 :: Booting Database
0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
Mon Apr 6 18:38:54 2015 :: [*****] BOOT: ---------------------[ Boot Log ]--------------------
Mon Apr 6 18:38:54 2015 :: Initializing libdl support...
Mon Apr 6 18:38:54 2015 :: Loading commands
Mon Apr 6 18:38:54 2015 :: Loading spec_funs...
Mon Apr 6 18:38:54 2015 :: Loading sysdata configuration...
Mon Apr 6 18:38:54 2015 :: Loading socials
Mon Apr 6 18:38:54 2015 :: Sorting skill table...
Mon Apr 6 18:38:54 2015 :: Loading herb table
Mon Apr 6 18:38:54 2015 :: Making wizlist
Mon Apr 6 18:38:54 2015 :: Loading Changes List
Mon Apr 6 18:38:54 2015 :: Loading force skills...
Mon Apr 6 18:38:54 2015 :: Done force skills
Mon Apr 6 18:38:54 2015 :: Loading force helps...
Mon Apr 6 18:38:54 2015 :: Done force helps
Mon Apr 6 18:38:54 2015 :: Loading ship prototypes...
Mon Apr 6 18:38:54 2015 :: [*****] BUG: Load_prototype_header: no match: Type
Mon Apr 6 18:38:54 2015 :: [*****] BUG: Load_prototype_header: no match: 1
Mon Apr 6 18:38:54 2015 :: Done ship prototypes
Mon Apr 6 18:38:54 2015 :: Initializing random number generator
Mon Apr 6 18:38:54 2015 :: Setting time and weather
Mon Apr 6 18:38:54 2015 :: Assigning gsn's
ASSIGN_GSN: Skill split s not found.
ASSIGN_GSN: Skill addpatrol not found.
ASSIGN_GSN: Skill true sight not found.
ASSIGN_GSN: Skill ship design not found.
ASSIGN_GSN: Skill shieldwork not found.
ASSIGN_GSN: Skill detrap not found.
ASSIGN_GSN: Skill parry not found.
ASSIGN_GSN: Skill fourth attack not found.
ASSIGN_GSN: Skill fifth attack not found.
ASSIGN_GSN: Skill bite not found.
ASSIGN_GSN: Skill claw not found.
ASSIGN_GSN: Skill sting not found.
ASSIGN_GSN: Skill tail not found.
ASSIGN_GSN: Skill brew not found.
ASSIGN_GSN: Skill fireball not found.
ASSIGN_GSN: Skill chill touch not found.
ASSIGN_GSN: Skill force bolt not found.
ASSIGN_GSN: Skill aqua breath not found.
ASSIGN_GSN: Skill blindness not found.
ASSIGN_GSN: Skill affect mind not found.
ASSIGN_GSN: Skill curse not found.
ASSIGN_GSN: Skill mask not found.
ASSIGN_GSN: Skill group masking not found.
ASSIGN_GSN: Skill sleep not found.
ASSIGN_GSN: Skill possess not found.
ASSIGN_GSN: Skill asdarian not found.
ASSIGN_GSN: Skill droid not found.
ASSIGN_GSN: Skill makeempgrenade not found.
Mon Apr 6 18:38:54 2015 :: Reading in area files...
Process 19224 exited with status = 1 (0x00000001)
(lldb) Abort (core dumped)
Amended on Tue 07 Apr 2015 08:38 PM by MattJ820
Nick Gammon Australia Forum Administrator #5
I don't see any messages there about a player connnecting. I don't understand either why you can't do a "bt". Maybe you have to switch threads or something, I'm not familiar with that particular version of the debugger.
Nick Gammon Australia Forum Administrator #6
MattJ820 said:

I used lldb on OSX to look at the core file and it gave me this out of comm.c. Anyone know how to fix this? I'm using swfote2.1.5


Can you give a link to the exact zip file you got this source from? I can try to reproduce under Linux where at least I know how to use gdb.

Also, did you change anything at all?
MattJ820 #7
http://sourceforge.net/projects/swfote/files/swfote/SWFotE%202.1.5%20Source/

The only thing I changed was I included <stdbool.h>, commented out typedef unsigned char bool in mud.h

In the makfile, I commented out NEED-DL = -ldl, commented out export symbols = -export dynamic, and then I removed -lcrypt from $(CC) -o $(SWR) $(O_FILES) $(L_FLAGS) -lm


Thanks for your help Nick. I tried to follow your guide for debugging and I wish I knew why the commands don't work in lldb despite being listed. it would at least point me in the right direction.
Nick Gammon Australia Forum Administrator #8
MattJ820 said:

I made a test character to test new features I coded but if i use goto to transfer to him, the mud crashes

...

The only thing I changed was I included <stdbool.h>, commented out typedef unsigned char bool in mud.h


Did you make changes or not? What new features? I compiled under Ubuntu without making any changes at all. I made a test character and did a "goto" to him. No crash. I transferred him to me. No crash.
MattJ820 #9
I backed out the changes I hadmade and the replicated the issue with a clean version. So, is the core dump because I'm compiling under OSX?
Nick Gammon Australia Forum Administrator #10
I ran my test through valgrind with these results:


cd ../area
valgrind --tool=memcheck ../bin/swr 1530


After doing a "goto":


==25819== Conditional jump or move depends on uninitialised value(s)
==25819==    at 0x4E52A3: strip_color (functions.c:353)
==25819==    by 0x4E63B4: is_name2 (handler.c:529)
==25819==    by 0x4E6549: nifty_is_name (handler.c:566)
==25819==    by 0x4EAC4F: get_char_world (handler.c:1777)
==25819==    by 0x455099: find_location (act_wiz.c:750)
==25819==    by 0x473D48: do_goto (build.c:864)
==25819==    by 0x4F6986: interpret (interp.c:418)
==25819==    by 0x49D7AF: game_loop (comm.c:602)
==25819==    by 0x49C6FA: main (comm.c:263)
==25819== 
==25819== Conditional jump or move depends on uninitialised value(s)
==25819==    at 0x4E5268: strip_color (functions.c:355)
==25819==    by 0x4E63B4: is_name2 (handler.c:529)
==25819==    by 0x4E6549: nifty_is_name (handler.c:566)
==25819==    by 0x4EAC4F: get_char_world (handler.c:1777)
==25819==    by 0x455099: find_location (act_wiz.c:750)
==25819==    by 0x473D48: do_goto (build.c:864)
==25819==    by 0x4F6986: interpret (interp.c:418)
==25819==    by 0x49D7AF: game_loop (comm.c:602)
==25819==    by 0x49C6FA: main (comm.c:263)


Code in question:


/*
 * Strips colors from a string --Keberus
 */
char *strip_color( const char *str )
{
   static char newstr[MAX_STRING_LENGTH];
   int i, j;

   if( !str || str[0] == '\0' )
   {
      return "";
   }

   for( i = j = 0; ( str[i] != '\0' ); i++, j++ )  // <--- line 353
   {
      if( str[i] == '&' )   // <---- line 355
      {
         i = i + 2;
      }
      newstr[j] = str[i];
   }
   newstr[j] = '\0';
   return newstr;
}


On the face of it, that code looks OK, however you could try a better initialization of i and j, eg.


   int i = 0, j = 0;


See if that helps.
Nick Gammon Australia Forum Administrator #11
Now that valgrind has alerted me to the function strip_color, I think there is a bug in it (and not what I suggested earlier).

My testing using gdb reveals that it is called with the argument "&w" like this:


#0  strip_color (str=0x7fffffffbc00 "&w") at functions.c:348


So, considering the "for" loop, we have this input:


& w 0x00


The variable "i" starts at zero, and we immediately detect the '&' character, so it adds two to "i". Then the for loop adds 1 to "i", so now i is equal to 3. However that puts "i" outside the string as it is only 2 bytes. In other words, "i" now points past the null-terminator. It could then conceivably increment massively, overwriting memory.

I suggest you change strip_color function to be:


/*
 * Strips colors from a string --Keberus
 */
char *strip_color( const char *str )
{
   static char newstr[MAX_STRING_LENGTH];
   int i, j;

   if( !str || str[0] == '\0' )
   {
      return "";
   }

   for( i = j = 0; str[i]; )
   {
      if( str[i] == '&' )
         i += 2;  // skip ampersand and color code
      else
         newstr[j++] = str[i++];  // copy character
   }
   newstr[j] = '\0';
   return newstr;
}


In fact even that could fail if it was fed with "&" on its own. This would be better:


/*
 * Strips colors from a string --Keberus
 */
char *strip_color( const char *str )
{
   static char newstr[MAX_STRING_LENGTH];
   int i, j;

   if( !str || str[0] == '\0' )
   {
      return "";
   }

   for( i = j = 0; str[i]; )
   {
      if( str[i] == '&' )
        {
        i++;    // skip ampersand
        if (str [i])
          i++;  // skip color code
        }
      else
         newstr[j++] = str[i++];  // copy character
   }
   newstr[j] = '\0';
   return newstr;
}
MattJ820 #12
I copied in the last code quote and over wrote the strip color function in functions.c but I still got a core dump using goto. I'm going to google lldb to find out why I can't BT to find what was going on when the dump happened. I wish it would work.

Thanks for helping Nick.


Could it be I need to initialize these other variables? I'll try that.

==25819== Conditional jump or move depends on uninitialised value(s)
==25819== at 0x4E52A3: strip_color (functions.c:353)
==25819== by 0x4E63B4: is_name2 (handler.c:529)
==25819== by 0x4E6549: nifty_is_name (handler.c:566)
==25819== by 0x4EAC4F: get_char_world (handler.c:1777)
==25819== by 0x455099: find_location (act_wiz.c:750)
==25819== by 0x473D48: do_goto (build.c:864)
==25819== by 0x4F6986: interpret (interp.c:418)
==25819== by 0x49D7AF: game_loop (comm.c:602)
==25819== by 0x49C6FA: main (comm.c:263)
==25819==
==25819== Conditional jump or move depends on uninitialised value(s)
==25819== at 0x4E5268: strip_color (functions.c:355)
==25819== by 0x4E63B4: is_name2 (handler.c:529)
==25819== by 0x4E6549: nifty_is_name (handler.c:566)
==25819== by 0x4EAC4F: get_char_world (handler.c:1777)
==25819== by 0x455099: find_location (act_wiz.c:750)
==25819== by 0x473D48: do_goto (build.c:864)
==25819== by 0x4F6986: interpret (interp.c:418)
==25819== by 0x49D7AF: game_loop (comm.c:602)
==25819== by 0x49C6FA: main (comm.c:263)
Amended on Sat 11 Apr 2015 01:45 AM by MattJ820
Nick Gammon Australia Forum Administrator #13
I think it was complaining about using data off the end of the string, which my change should have fixed.
Nick Gammon Australia Forum Administrator #14
You don't need to use lldb, I just tested on my Mac using gdb.

After it crashed, I got a backtrace:


(gdb) bt
#0  0x00007fff931e182a in __kill ()
#1  0x00007fff960ccb6c in __abort ()
#2  0x00007fff9609e89f in __chk_fail ()
#3  0x00007fff9609e6d9 in __sprintf_chk ()
#4  0x00000001000194f8 in show_char_to_char_0 (victim=0x100941000, ch=0x100943a00) at act_info.c:520
#5  0x000000010001adab in show_char_to_char (list=0x100941000, ch=0x100943a00) at act_info.c:816
#6  0x000000010001bad1 in do_look (ch=0x100943a00, argument=0x1002400d4 "") at act_info.c:1008
#7  0x0000000100047ee3 in transfer_char (ch=0x100941000, victim=0x100943a00, location=0x1004bcfc0) at act_wiz.c:813
#8  0x00000001000481f6 in do_transfer (ch=0x100941000, argument=0x7fff5fbff625 "") at act_wiz.c:864
#9  0x0000000100116d56 in interpret (ch=0x100941000, argument=0x7fff5fbff621 "nick") at interp.c:418
#10 0x00000001000a57dd in game_loop () at comm.c:602
#11 0x00000001000a436c in main (argc=2, argv=0x7fff5fbffb08) at comm.c:263
Nick Gammon Australia Forum Administrator #15
A bit more debugging reveals line 520 in act_info.c is this:


520	        sprintf(colorbuf, "&w&W%s", color_str( AT_IMMORT, ch) );


AT_IMMORT is 32, so let's see what color_str gives us:


(gdb) p  color_str( 32, ch)
$2 = 0x100251d08 "\033[1;37m"


So we are putting this into colorbuf:


&w&W\033[1;37m


And how big is colorbuf?


    char colorbuf[4];


Problem.

I made colorbuf 40 bytes and it ran without crashing.
Amended on Sat 11 Apr 2015 03:39 AM by Nick Gammon
MattJ820 #16
That worked Nick, thanks for your help.