Bug-NUM_FOR_EDICT Error: Bad Pointer

[sPlOrYgOn]

Well I really need help with this bug...
If anyone know how to debug good maybe he can help...
or if anyone knows what else might be causing this error...
it could be a lot of help if you guys tell us your configurations and all..
I know absolutely that the bots do not crash on de_dust or awp_map on my computers...
btw what version source code did you use?

[biohazerd87]

How many people are you putting in the game. It seems for me the more people I put into a game the faster it will crash. Per say a game with 6 bots will probly play for 5 mins and a game with 20 bots will crash in 25 seconds.
This may or may not help but i hope it does

[Pierre-Marie Baty]

sPlO, instead of putting your checks in pfnIndexOfEntOffset() and the likes, just #undef the INDEXENT and ENTINDEX macros and redefine them with your check included.

If you want to FIX that bug (and not PATCH it), instead of just returning from ENTINDEX when the pointer is NULL, provoke a crash here (by a zero divide, for example). This way when Windows will crash, you can click on "Debug" and the debugger will kick in right at the spot where ENTINDEX was called.

[Dethpod]

Gentlemen,

The "NUM_FOR_EDICT" error also happens on my linux Cs 1.5 server.

Hopefully this helps in the debug on the error:
Server Name: Test Server
Server IP : 172.21.10.175:27015
Mod : cstrike
Map : de_vegas

Last 5 lines in hlds_l.log are:
----------------------------------------------------------------------
Visibility Table out of Date. Rebuilding... (47%)
Visibility Table out of Date. Rebuilding... (53%)
Visibility Table out of Date. Rebuilding... (58%)
L 05/13/2004 - 13:25:52: FATAL ERROR (shutting down): NUM_FOR_EDICT: bad pointer
FATAL ERROR (shutting down): NUM_FOR_EDICT: bad pointer

-Dethpod

[sPlOrYgOn]

NO F*ING WAY!!!
I put a divide by zero into those 2 functions...
and guess what...
it didn't work..
it just goes through as if those 2 functions aren't causing this crash....
What I had in the ENTINDEX and INDEXENT functions were:

if (FNullEnt (pEdict)) 1/0;

change pEdict to iEdictNum for INDEXENT..
it just gives me the error message.. and shuts down itself...
it doesn't crash at the divide by zero part...
We probably need someone who knows a lot about where NUM_FOR_EDICT is called

[edit]
searched around on google and found out that this error can also happen if the number of entity slots are full...
which can be caused by maps...
and I'm guessing that cs_office probably uses a LOT of entities...
maybe somehow lower the entity usage of the bot? (probably impossible)
[/edit]

[Pierre-Marie Baty]

I'm not sure the code you posted actually crashes. IMO it's not executed at all because you don't assign the final value of the computation to a variable. So the compile-time optimization just scraps it and doesn't even include the "if" that's just before.

You must assign your value to a variable.

I have a function that I call in my bot code when I want to crash voluntarily the game at some point.

void TerminateOnError (const char *fmt, ...)
{
   // this function terminates the game because of an error and prints the message string
   // pointed to by fmt both in the server console and in a messagebox.
 
   va_list argptr;
   char string[1024];
 
   // concatenate all the arguments in one string
   va_start (argptr, fmt);
   vsprintf (string, fmt, argptr);
   va_end (argptr);
 
   // send the error message to console, messagebox, and also in the logfile for developers
   ServerConsole_printf ("FATAL ERROR: %s", string); // print to console
   MessageBox (0, string, "RACC - Error", NULL); // print to root-level message box
 
   // do we need to close the debug log file ?
   if (DebugLevel.fp != NULL)
	  fclose (DebugLevel.fp); // close the file
   DebugLevel.fp = NULL;
 
   // is it better to just exit or shall we crash here to help debugging ?
   if (server.developer_level > 0)
	  string[0] /= (string[0] = 0); // do a nice zero divide error for developers :)
 
   exit (1); // normal exit for non-developers (with error condition)
}

As you can see I use one variable (here the 1st element of the string array) as support for the faulty computation. I couldn't even write " / 0" because the compiler would refuse compiling and complain about a zero divide in the code. That's why I think your "breakpoint" doesn't even work.

If it does perhaps FNullEnt fails to determine the entity pointer is bad.

Every entity is supposed to have a classname. So try doing

if (STRING (pEdict->v.classname)[0] == 0)

instead of FNullEnt. If the entity pointer is bad, you will read at a forbidden memory location and provoke an access violation anyway, hence a crash, so this is in all cases what you want. And in case it wouldn't want to crash, just append your zero divide to that line.

[sPlOrYgOn]

actually what i did was this...

int bleh () { return 0; }
int blah = 0;
// then in the ENTINDEX and INDEXENT
if (FNullEnt (pEdict)) blah = 1 / bleh();

I didn't put that in the above example just to simplify the example..
Did that to stop MSVC from complaining...
so annoying...
[edit]
okay now my ENTINDEX and INDEXENT functions look like this..

inline int	  ENTINDEX(edict_t *pEdict)			{ if (STRING (pEdict->v.classname)[0] == 0); return (*g_engfuncs.pfnIndexOfEdict)(pEdict); }
inline edict_t* INDEXENT( int iEdictNum )		{ if (iEdictNum == 0) iEdictNum /= iEdictNum; return (*g_engfuncs.pfnPEntityOfEntIndex)(iEdictNum); }

still won't make it crash...
I'm really starting to think that these 2 functions aren't causing it..
[/edit]

[[NvT]_KaszpiR_]

PMB, does it mean that the optimization flags in makefile can causing some code corrupion and thus increasing the ability of the bug we discuss here?

[sPlOrYgOn]

nope it doesn't...
I've compiled it in debug, maximum speed, and minimum size.
makes no difference.

[Pierre-Marie Baty]

@KaszpiR: no, but if you do

if (condition)
a / b;

the result of a / b isn't fed into any variable, hence the computation is intrinsically useless for the program, hence the if condition is useless too. And I wouldn't be surprised that any decent optimizer just drops it from the code.

@Splo:
change
inline int ENTINDEX(edict_t *pEdict) { if (STRING (pEdict->v.classname)[0] == 0); return (*g_engfuncs.pfnIndexOfEdict)(pEdict); }
to
inline int ENTINDEX(edict_t *pEdict) { if (STRING (pEdict->v.classname)[0] == 0) blah=1/bleh(); return (*g_engfuncs.pfnIndexOfEdict)(pEdict); }

And since 0 divided by anything oughta be 0, I'm not sure the optimizer doesn't even execute this:
if (iEdictNum == 0) iEdictNum /= iEdictNum;
Same problem. MAKE SURE your code will be executed.

When you say it doesn't make it crash, the point is not to MAKE it crash or not, the point is to land into the debugger when it does (because it does crash already).