Bug!!! Str_cmp: Null astr

Hi,

I just set up my Smaug version 1.4 and I keep getting this bug. Str_cmp: Null Astr and I cant figure out where its coming from. It use to pop up once every couple minutes and now its popping up about 2 times a minute. Anyone out there with a bug fix or know what the bug is?

Thanks,
Cynthia

Well, that means that somewhere in the code, something is calling str_cmp( (something null), (something maybe not null) ) and it's complaining at you.

If you want to see where, one way to do it is the following: (I'm assuming you're on Unix and know how to use gdb, the debugger)
Go to the str_cmp function, and find the line where it generates that bug message.
First after that, insert:
[code]
assert(1 == 2); // assert (false) <-- will always fail
[/code]
or something like;
[code]
int * p = NULL;
*p = 35213; // NEVER do this in real life. :)
[/code]
In the first case, you may have to include <assert.h>.

Basically, what we're doing here is doing something really stupid and forcing the program to crash, so that a core file is generated and we can backtrace up through the function calls.

So now you have your core file (or you just run the executable through gdb directly, maybe a better idea) and you can just type "backtrace" at the GDB prompt, and it will give you the call stack: the list of functions that were called up to the point where it crashed. Then you just move up the stack frame (typing... "up") and look at what functions were called. At least then you can get a general idea of what things were called when, and which part of the code is calling str_cmp with a null argument.

If you're running on Windows, you won't be able to use GDB; you'll have to use your windows debugger (e.g. Visual Studio) but the basic idea is the same.

Let me know if this helps... :)

void bug( const char *str, ... )
{
char buf[MSL];
#if !defined(__CYGWIN__)
void *array[20];
size_t size, i;
char **strings;
#endif

if ( fpArea != NULL )
{
int iLine;
int iChar;

if ( fpArea == stdin )
iLine = 0;
else
{
iChar = ftell( fpArea );
fseek( fpArea, 0, 0 );
for( iLine = 0; ftell( fpArea ) < iChar; iLine++ )
{
while ( getc( fpArea ) != '\n' )
;
}
fseek( fpArea, iChar, 0 );
}
log_printf( "[*****] FILE: %s LINE: %d", strArea, iLine );
}

strcpy( buf, "[*****] BUG: ", MSL );
{
va_list param;

va_start( param, str );
vsnprintf( buf + strlen(buf), MSL, str, param );
va_end( param );
}
log_string( buf );

#if !defined(__CYGWIN__)
if( !fBootDb )
{
size = backtrace( array, 20 );
strings = backtrace_symbols( array, size );

log_printf( "Obtained %zd stack frames.", size );

for( i = 0; i < size; i++ )
log_string( strings[i] );

free( strings );
}
#endif

return;
}

The above code is what we now use for our bug() function. The string bug you are getting will trigger this. the results will end up in your logs and on screen if you're there to see it happen. At the top of db.c you will need:

[code]
#if !defined(__CYGWIN__)
#include <execinfo.h>
#endif
[/code]

As I'm sure you can also guess, this does not work in Cygwin, so if you're using that you'll have to come up with another approach.

I forget who pointed me to this backtrace stuff, but it beats the hell out of forceably crashing the mud to get a trace.

Ah, that's pretty clever. I didn't know you could do that, but I suppose it makes sense that the runtime library can do it if GDB can do it. :)

This probably only works if your code is compiled in debug mode, but then again, everyone's is by default I believe.

I have no idea what debug mode is, so I'm guessing it's not required. Whoever it was that pointed me to this got it from the GNU library somewhere. I lost the link though. And yes, it's very clever indeed.

Debug mode is a "windowsism" of generating code with all debug info (e.g. symbol names) included. If you don't compile this way, you won't get any useful information out of GDB because it won't be able to tell you what the symbol names are.

This is what the -g2 and -g3 flags to GCC do.

The upside to this mode is that you have symbols so you can do stack traces and that sort of stuff; downside is precisely that you have symbols so your executable is significantly bigger than it would normally be... my executable is 23 mb, for example, when it really shouldn't be anywhere near that size. That's because I compile in full debug mode (-g3 - the one that includes macroes I believe.)

Didn't we have a discussion about this a little bit ago? Maybe it's just a vocabulary problem. :P

Ah. I thought maybe you were referring to some sort of special mode. I compile with -g2 as a rule. There's little point in not having debug symbols available. Crashes happen, often when you least expect them, and not being able to track down what happened at the time of the crash is a pain. Especially if it's an intermitent problem that doesn't come up often.

Good Lord! 23MB? Even with -g3 and all the junk I throw into my code my exe size only ever tops out at 9MB. I really didn't think that all my fat cutting and such was *THAT* dramatic, but maybe I'm wrong? :P

Well, I also use a whole bunch of other libraries. For example, I statically link into a parser generator (based on Lex and Yacc), that I use for compiling the scripting language I wrote for my MUD.

I also link (dynamically) into BerkeleyDBXML, which I'm tentatively using as a new storage format. For now, I only am storing player "vaults" (like a bank but for objects... lockers if you will) in this XML format, but I hope to (at some point) store EVERYTHING that SMAUG stores in a file in this database thing.

I think that's where the extra 14 mb come from. I remember that before I put those in, my executable was like 10mb in size. And there really is a lot of junk in there; I haven't bothered trimming it at all, even if I should. :P

Oh, my MUD is also fully in C++, with quite a few classes and inherited things... (not everything yet, but I'm working on that :P) I also make use of the STL. Those may have something to do as well with the increased size.