On Sun, 15 Oct 2000, Donald P. Taylor wrote:
> I was getting an error about sprintbits being defined twice....one was in
> db.c and the other was in dg_olc.c. Not knowing what to do with them
> since they took different data I just made them static.
The best thing to do in this case would be to rename one of the functions
and all calls to that function should be changed to use the new name. That
will prevent these kinds of conflicts. Actually, the best thing to do
would be to see if the two functions are doing the same thing and pick the
best of the two and convert all other calls to use the better one.
> The mud compiled I logged on and the pfile was created ok. Logged off,
> logged on and walked around. Did a who and POOF game hangs. I played
> around and it hangs on who, score, inventory.
I use a technique called "wolf-fencing" to track down errors like this.
Basically, you push to a logfile (most likely to syslog in this case) a
set of information at certain points in the code. To make this easy on
myself, I did something like this in utils.h:
#define LOG(var) mudlog(var, LOG_SYSTEM, 58, true)
This allows me to do this:
int a;
LOG("Declared a");
a = 1;
LOG("Set a to 1");
int b = dice(1, 6);
sprintf(buf, "Randomly set b to %d"), b);
LOG(b);
What you do is you log into the mud, and in your shell you want to do:
cd /location/to/where/syslog/is/at/
tail -f syslog (NOTE: To stop tail'ing the file, hit CTRL-C)
This will display things to the screen as they are written to the logfile
and this allows you to see what is happening as it happens.
So, you put things like this in do_who:
ACMD(do_who)
{
//... 5 lines of code
LOG("A");
//... 5 more lines of code
LOG("B");
//... even more code
LOG("C");
//... and more code
LOG("D");
}
Insert the LOG() calls in places before/after the following:
loops, switches, sets of logic that go together, function calls.
You'll end up with something like this in the syslog:
Oct 14 01:03:52 :: [A]
Oct 14 01:03:52 :: [B]
Oct 14 01:03:52 :: [C]
This means that the code executed "C", but nod "D". So the problem
manifests itself in the code between C and D. Move C and D closer to each
other until you can isolate the code. This does not mean that the problem
code is ALWAYS there. Somestimes a problem lies elsewhere, but does not
appear until certain code does something.
If you have function calls between the working and failure points, then
the problem could be in the called function so you'll have to wolf-fence
that function as well.
If you have an interactive debugger that lets you set variable watches,
breakpoints, stepping-through-code, etc. then you may want to use it,
but I learned how to code before those existed in great quantities and
long before Windows ever thought about existing. I prefer to wolf-fence
because I can do it quickly and know how to read the results.
Etemology: Shepards in the days of yore had problems with wolves attacking
flocks at night. The whole flock was at danger and by the time the
shepards fought throught chaos of the whold flock many sheep would be dead
or dying. They started keeping their sheep in small grounds that were
contained in small pens. This would force the wolves to enter a confined
area to reach the sheep. Once one pen would erupt in chaos, the farmers
knew right where the wolves were at and could more easily trap them and
kill them. This put only a small portion of the flock at risk instead of
the whole thing. Likewise, you are confining your code into sections and
trapping the problem between two known locations.
If you are able to fence in the problem, but cannot kill it, send us the
code and we can take a look at it to let you know what maybe went wrong.
--
Zeavon Calatin, MageMaster of the Realms
Spear of Insanity
http://spear.kilnar.com/ telnet://spear.kilnar.com:1066
+------------------------------------------------------------+
| Ensure that you have read the CircleMUD Mailing List FAQ: |
| http://qsilver.queensu.ca/~fletchra/Circle/list-faq.html |
+------------------------------------------------------------+
This archive was generated by hypermail 2b30 : 04/10/01 PDT