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

"Corrupted" room names

Posted by Darwin on Wed 29 Aug 2007 04:00 PM — 11 posts, 37,633 views.

Darwin USA #0
I have an issue where seemingly random room names are being corrupted, for lack of a better word. The room names get replaced with what appears to be a random string of non-alphanumeric characters. Sometimes, though, it gets replaced with other strings found somewhere in the game such as an item's short description or an IP address.

This is on a heavily modified SMAUG 1.4a.

Has anyone else had this problem?
If so, did you get it fixed and how?
David Haley USA #1
This could come from several things, the most likely culprits being stack overflows or bad string writes that corrupt string endings. The easiest way to solve this problem is to run your MUD through Valgrind (assuming you have access to it, of course).
Valcados #2
What things have you worked on around the time the problem arose? How frequent is the problem? It sounds like a nasty case of bad pointer management, I doubt we'll be able to help any more than valgrind, but if we can, we'll need more info than you gave.
Darwin USA #3
This problem was occurring before I began to work with the code so I am not sure if there was a period of time where this was not occurring.

As for how often it occurs, I'm not certain. We have nearly 8,000 rooms and to check each one to make sure its name is correct would be very time consuming. Usually, these only come to my attention when one of our players wanders into an affected room and says "hey, this room is messed up." Although, it has been known to happen to more than one room at a time, but it doesn't appear to ever be very many.

I've never used valgrind before, so I'm a bit lost on how to use it.
David Haley USA #4
It's pretty easy, just run "valgrind (yourprogram)", instead of e.g. "valgrind ../src/smaug". It'll tell you if something happens that causes memory corruption, although if you can't reproduce the problem by yourself you might have to wait a bit until it does happen.
Darwin USA #5
Quote:
It's pretty easy, just run "valgrind (yourprogram)", instead of e.g. "valgrind ../src/smaug".

I'm afraid you'll have to be a little more specific than that. I tried that and the only output I get is as if I typed valgrind without an argument.

valgrind ./startup 6050 (from within the src directory)
valgrind ../src/smaug 6050 (from within the area directory)
valgrind ../src/startup 6050 (from within the area directory)
valgrind smaug 6050 (from within the src directory)

None of those worked. Am I doing something wrong or missing something? I thought I was typing in the right command as your example states but... I dunno.
David Haley USA #6
What do you mean when you say that it didn't work? It's possible that you don't have valgrind installed; in that case you'll have to install it or ask whoever administers your system to install it for you.
Darwin USA #7
Valgrind with no argument yields this:
$ valgrind
usage: valgrind --tool=<toolname> [options] prog-and-args

  common user options for all Valgrind tools, with defaults in [ ]:
    --tool=<name>             Use the Valgrind tool named <name>
    --help                    show this message
    --help-debug              show this message, plus debugging options
    --version                 show version
    -q --quiet                run silently; only print error msgs
    -v --verbose              be more verbose, incl counts of errors
    --trace-children=no|yes   Valgrind-ise child processes? [no]
    --track-fds=no|yes        Track open file descriptors? [no]

  uncommon user options for all Valgrind tools:
    --run-libc-freeres=no|yes Free up glibc memory at exit? [yes]
    --weird-hacks=hack1,hack2,...  [none]
         recognised hacks are: ioctl-VTIME truncate-writes lax-ioctls
    --signal-polltime=<time>  time, in mS, we should poll for signals.
                              Only applies for older kernels which need
                              signal routing [50]
    --lowlat-signals=no|yes   improve wake-up latency when a thread receives
                               a signal [no]
    --lowlat-syscalls=no|yes  improve wake-up latency when a thread's
                               syscall completes [no]
    --pointercheck=no|yes     enforce client address space limits [yes]

  user options for Valgrind tools that report errors:
    --logfile-fd=<number>     file descriptor for messages [2=stderr]
    --logfile=<file>          log messages to <file>.pid<pid>
    --logsocket=ipaddr:port   log messages to socket ipaddr:port
    --demangle=no|yes         automatically demangle C++ names? [yes]
    --num-callers=<number>    show <num> callers in stack traces [4]
    --error-limit=no|yes      stop showing new errors if too many? [yes]
    --show-below-main=no|yes  continue stack traces below main() [no]
    --suppressions=<filename> suppress errors described in <filename>
    --gen-suppressions=no|yes print suppressions for errors detected [no]
    --db-attach=no|yes        start debugger when errors detected? [no]
    --db-command=<command>    command to start debugger [gdb -nw %f %p]
    --input-fd=<number>       file descriptor for input [0=stdin]


  Extra options read from ~/.valgrindrc, $VALGRIND_OPTS, ./.valgrindrc

  Valgrind is Copyright (C) 2000-2004 Julian Seward
  and licensed under the GNU General Public License, version 2.
  Bug reports, feedback, admiration, abuse, etc, to: valgrind.kde.org.

  Tools are copyright and licensed by their authors.  See each
  tool's start-up message for more information.

$


This is what I get when I try any of the previous mentioned arguments.

$ valgrind ./startup 6050
usage: valgrind --tool=<toolname> [options] prog-and-args

  common user options for all Valgrind tools, with defaults in [ ]:
    --tool=<name>             Use the Valgrind tool named <name>
    --help                    show this message
    --help-debug              show this message, plus debugging options
    --version                 show version
    -q --quiet                run silently; only print error msgs
    -v --verbose              be more verbose, incl counts of errors
    --trace-children=no|yes   Valgrind-ise child processes? [no]
    --track-fds=no|yes        Track open file descriptors? [no]

  uncommon user options for all Valgrind tools:
    --run-libc-freeres=no|yes Free up glibc memory at exit? [yes]
    --weird-hacks=hack1,hack2,...  [none]
         recognised hacks are: ioctl-VTIME truncate-writes lax-ioctls
    --signal-polltime=<time>  time, in mS, we should poll for signals.
                              Only applies for older kernels which need
                              signal routing [50]
    --lowlat-signals=no|yes   improve wake-up latency when a thread receives
                               a signal [no]
    --lowlat-syscalls=no|yes  improve wake-up latency when a thread's
                               syscall completes [no]
    --pointercheck=no|yes     enforce client address space limits [yes]

  user options for Valgrind tools that report errors:
    --logfile-fd=<number>     file descriptor for messages [2=stderr]
    --logfile=<file>          log messages to <file>.pid<pid>
    --logsocket=ipaddr:port   log messages to socket ipaddr:port
    --demangle=no|yes         automatically demangle C++ names? [yes]
    --num-callers=<number>    show <num> callers in stack traces [4]
    --error-limit=no|yes      stop showing new errors if too many? [yes]
    --show-below-main=no|yes  continue stack traces below main() [no]
    --suppressions=<filename> suppress errors described in <filename>
    --gen-suppressions=no|yes print suppressions for errors detected [no]
    --db-attach=no|yes        start debugger when errors detected? [no]
    --db-command=<command>    command to start debugger [gdb -nw %f %p]
    --input-fd=<number>       file descriptor for input [0=stdin]


  Extra options read from ~/.valgrindrc, $VALGRIND_OPTS, ./.valgrindrc

  Valgrind is Copyright (C) 2000-2004 Julian Seward
  and licensed under the GNU General Public License, version 2.
  Bug reports, feedback, admiration, abuse, etc, to: valgrind.kde.org.

  Tools are copyright and licensed by their authors.  See each
  tool's start-up message for more information.

$

It gives the same output no matter what arguments I supply to the valgrind command.
David Haley USA #8
Hmm, mine defaults to the memcheck tool. Try:
valgrind --tool=Memcheck (your program)

also try without caps if necessary.
Gohan_TheDragonball USA #9
no you are not going to be calling the startup script, but the actual program itself:

cd smaug/area
valgrind ../src/smaug 6050

(assuming 6050 is the port you are using)
Darwin USA #10
Well, that was it. Had to add --tool=memcheck, it didn't like the capitalized Memcheck.

Thanks for the help.