Re: Server crash in /city/anthony/prison

[Neil Muller <>]

On Fri, Jun 16, 2000 at 09:32:23PM -0700, Mark Wedel wrote:
> Jan Echternach wrote:
> > With llevDebug instead of llevError, you would get the effect of
> > wrapping the log message in an if (debug) statement.  But I prefer all
> > indications of errors to be logged with llevError, because this allows
> > me to trap all errors immediately after they are detected with a simple
> > "break LOG if logLevel == llevError" in gdb, provided that I run the
> > server "interactively" from gdb.
OK, after the heads-up on the logging functions, attached is a updated 
patch. I've also got around to commenting the additions.

>  In reality, a much more robust logging method should be redone.  Right now,
> there are many files or other places that have something like a #define
> ATTACK_DEBUG or the like, and if that isn't commented out, you get a bunch of
> debug messages about attack.

I've had a bit of a look at the code, so if nobody else volunteers, I can 
have a go at starting a clean-up, but I won't have time to do anything for 
at least a couple of weeks.

>  A better method, which many other programs do, is differing log output
> depending on options.  For example, you could do something like 'crossfire
> -attackdebug -imagedebug' and get the debug messages in those areas but not
> every place else and not need to recompile before doing so.

I see that currently there are 4 log-levels specified. Probably whats needed
is something of like:
   Serious Errors - Always show up
   Area specific errors - i.e. map_error, attack_error, etc. For things 
      which are non-fatal to the server but should never happen in the first 
      place. Propbably normally on , but can be turned off for
      whatever reason, i.e. to minimise cruft in the logs while tracking a
      given problem
    Area specific debug information - Same type's as above. Information that
      useful to solving the problem should fall into this category. Should
      imply debug for the same category is on. Probbaly off for most people.
    
    An info level and some sort of misc catch-all are probably also useful. 

    Currently, debug macros that can be defined include attacks,
    alchemy, skills, throwing, input, pickup, lights and malloc. Some
    reworking of these is almost certainly needed. 
    
-- 
Neil Muller

A Gentleman is someone who knows how to play the bagpipes
   and doesn't.

I see no need to concern myself with the medical professions neurotic 
hangups about food.
--- server/monster.c.orig	Sun Jun 18 01:34:11 2000
+++ server/monster.c	Sat Jun 17 23:02:32 2000
@@ -1262,6 +1262,29 @@
           *line = '\0';
           if (last != line)
             msgs->keywords[msgnr][keywordnr++] = strdup_local(last);
+	  else {
+	        if (keywordnr<nrofkeywords)
+		{
+		   /* Whoops, Either got || or |\n in @match. Not good */
+		   msgs->keywords[msgnr][keywordnr++] = strdup_local("xxxx");
+		   /* We need to set the string to something sensible to    *
+		    * prevent crashes later. Unfortunately, we can't set to *
+		    * NULL, as that's used to terminate the for loop in     *
+		    * talk_to_npc.  Using xxxx should also help map         *
+		    * developers track down the problem cases.              */
+		   LOG (llevError, "Tried to set a zero length message in parse_message\n");
+		   /* I think this is a error worth reporting at a reasonably *
+		    * high level. When logging gets redone, this should       *
+		    * be something like MAP_ERROR, or whatever gets put in    *
+		    * place. */
+		   if (keywordnr>1)
+			   /* This is purely addtional information, should *
+			    * only be gieb if asked */
+			   LOG(llevDebug, "Msgnr %d, after keyword %s\n",msgnr+1,msgs->keywords[msgnr][keywordnr-2]);
+		   else
+			   LOG(llevDebug, "Msgnr %d, first keyword\n",msgnr+1);
+		}
+	  }
           last = line + 1;
         }
       last = cp;