Bug-NUM_FOR_EDICT Error: Bad Pointer

[sPlOrYgOn]

well it doesn't exactly crash..
hlds shuts down the server properly with a -1 return..
and if you try it with a calculator 0/0 is undefined/error.
the compiler even warns me that there could be a zero divide.

[edit]
well i've changed it to

if (iEdictNum == 0) iEdictNum = 1 / iEdictNum;

still it does NOT go through with this or the other thing..
I REALLY think something else is doing it..
[/edit]

[Whistler]

Originally Posted by Pierre-Marie Baty

void TerminateOnError (const char *fmt, ...)
{
   va_list argptr;
   char string[1024];
 
   // concatenate all the arguments in one string
   va_start (argptr, fmt);
   vsprintf (string, fmt, argptr); // this isn't secure, and may cause buffer overrun.
   // I would suggest you change it to: _vsnprintf(string, sizeof(string), fmt, argptr);
   va_end (argptr);
......
}

...comments above

[sPlOrYgOn]

Okay I got a new plan of action!
How about everyone who crashes a lot post all the maps they crash at...
Maybe we can find some similarities between them and see what the bot does wrong with the certain thing..
so far I only crash on cs_office.

[edit]
new info...
only ENTINDEX can cause a "NUM_FOR_EDICT: bad pointer" error..
if INDEXENT was causing the error it would be "EDICT_NUM: bad number %i".
[/edit]

[Dethpod]

sPlOrYgOn,

You got it. I will start compiling a list of maps that PodBot2.1-mm crashes on.

-Dethpod

[Pierre-Marie Baty]

Well that is very nice Whistler, but tell me, why on this frikkin Earth would I want to check for possible h@x0r 3xpl0its and buffer overflows on a function that I myself have written and that I myself am the only one using ??? o_O

/me gonna practice breaking into my own code now...

[sPlOrYgOn]

sorry Dethpod but I found a way to break point when Sys_Error is called..
I'm testing it right now..
It stopped at the break point but it's currently inside the Sys_Error function..
I built the dll with debug info during the compiling and the linking.
my call stack says

PODBOT_MM! Sys_Error(char const *) + 27 bytes
METAMOD! 6b2644e6()

[edit]
after some more work I now know that the last call to ENTINDEX is from pfnMessageBegin.
[/edit]
[edit2]
well I can't seem to solve it because in pfnMessageBegin it already runs FNullEnt against the Edict.
I also tried STRING (ed->v.classname)[0] == 0 still no.
If I remember correctly pfnMessageBegin shouldn't catch message calls in the bot dll..
So that means the game dll is using MESSAGE_BEGIN with a messed up edict?
[/edit2]

[biohazerd87]

So does this mean we have figured out the problem or are we still working on it?

[Whistler]

like this, if ANY user connected to a server running RACC typed a command which is more than 128 characters will cause buffer overrun and crash the server...

      char pcmd[129]; // no way, I hate pointers...
      char arg1[129];
      char arg2[129];

      strcpy (pcmd, CMD_ARGV (0));
      strcpy (arg1, CMD_ARGV (1));
      strcpy (arg2, CMD_ARGV (2));

[Pierre-Marie Baty]

Nice try Whistler, but I know that already, that wouldn't work
It is impossible for a HL client to send a client command of more than 128 bytes long

it's not to an old monkey that one can teach how to pull funny faces

/me pulls funny face

[biohazerd87]

So have you fixed the NUM_FOR_EDICT error? or are we still waiting