Valhalla Legends Archive

I finally finished all of my interfaces for my bot and definitions for those interfaces and put it all together.  In _tmain(...) it creates an object of BotConnection which calls a member function void *Connect();.  For some reason, this causes three runtime errors.  The first two errors are: The instruction at <memory address> referenced memory at <memory address>.  The memory could not be read., and the third one is a debug error involving an assertion failure.  For some reason, this only occurs when I call this member function.  I tried just for testing calling functions like Disconnect, Reconnect, and used other objects such as BotLoad and called things like LoadConfig, etc. and everything worked fine.  It just seems to be this function, and there's nothing wierd about it.  I even tried debugging the program and the error occurs at the function call, NOT in the function...Help?

int _tmain(int argc, _TCHAR* argv[])
{
   BotConnection *startBot = new BotConnection;
   startBot->Connect();
   return 0;
}

Break in with the debugger when you get one of these runtime errors. Have a look at the stack trace-- it should be pretty obvious where the problem lies.

After I did some more debugging I actually figured out that it was occuring when BotConnection was being initialized.  When I step into the declaration newop.cpp displays as expected containing the following code:

// newop operator new(size_t) for Microsoft C++
#include <cstdlib>
#include <new>

_C_LIB_DECL
int __cdecl _callnewh(size_t size) _THROW1(_STD bad_alloc);
_END_C_LIB_DECL

void *__cdecl operator new(size_t size) _THROW1(_STD bad_alloc)
   {   // try to allocate size bytes
   void *p;
   while ((p = malloc(size)) == 0)
      if (_callnewh(size) == 0)
         _STD _Nomemory();
   return (p);
   }

/*
* Copyright (c) 1992-2002 by P.J. Plauger.  ALL RIGHTS RESERVED.
* Consult your license regarding permissions and restrictions.
V3.13:0009 */

I debugged this code while it executed, when it finishes (and before it gets to the function call in WindowsBot.cpp in _tmain(...) it has to break.  And the file that shows up is strlen.asm and it occurs on this line in the file:

main_loop:
       mov     eax,dword ptr [ecx]     ; read 4 bytes (this line)

I'm sort of confused by this, but perhaps people with more experience with this type of thing aren't.  I also tried looking at the constructors and such in BotConnection and everything is fine.  I even tried commenting them out to see what would happen and the same error occurs.


which calls a member function void *Connect();.


Looks to me like it should be void Connect();

Should also delete the pointer at the end.

Should also put () after new BotConnection.

If new is failing, check the classes constructor.

Quote from: Eibro[yL] on August 13, 2004, 05:52 PM
If new is failing, check the classes constructor.

I did, and like I said I even tried commenting out and the same thing is happening.  I also did what $torm suggested and to no avail...

Eibro, I could send you the project on MSN if you'd like (I don't want to publicly post it) and when you have time and you want to look at it, see if you can find the problem.  

Are you chaining constructors? ie, calling a different constructor from within the first constructor, perhaps with default values?

Sort of figured it out, pinpointed it to a problem with the constructors when one of the objects multiply derives.  It seems that when the object BotConnection is created it calls the constructor of BotLoad and so on up the heirarchy.  BotLoad dervies from BotFunctions and Botdata, each have constructors, and it seems like the constructor in BotFunctions is being called twice, and on the second call it causes that error.  I commented out the code in the BotFunctions constructor and just made it a default constructor, and the same thing continued to happen.  Anyways, Eibro is going to help me debug it later, we'll see if that can fix it up.  

Problem fixed.  To think how many problems you can solve by paying attention to compiler warnings, and not just errors.  

Quote from: Sargera on August 14, 2004, 11:20 PM
Problem fixed.  To think how many problems you can solve by paying attention to compiler warnings, and not just errors.  

An easy way to make sure you do that is to build with /W4 /WX.

Quote
/W<n> set warning level (default n=1)
/WX treat warnings as errors

Quote from: Skywing on August 15, 2004, 10:08 AM

Quote from: Sargera on August 14, 2004, 11:20 PM
Problem fixed.  To think how many problems you can solve by paying attention to compiler warnings, and not just errors.  

An easy way to make sure you do that is to build with /W4 /WX.

Quote
/W<n> set warning level (default n=1)
/WX treat warnings as errors

Thanks, this should not only help avoid more runtime errors but bad coding as well.