none
Allocation problem

    Question

  • I'm using VS 2002, and I'm having an allocation problem. When the program tries to allocate a new block, access violation occurs, but not in my code and not always. Debugger says the error is in the CheckBytes(...) function, and as far as I can tell, it's a function that is called when the 'new' operator is used (when I break the execution, VS opens the dbgheap.c file). I sent my project to someone who has VS 2005 and the problem disappeared... Perhaps the problem is in some memory management library?

    Thanks!

    Friday, May 11, 2007 7:56 AM

Answers

  • If I remember rightly, in 2005 there is a difference in how new reports an error. Instead of it returning null it actually throws an error. So, is the crash you are getting an unhandled exception?
    Saturday, May 12, 2007 4:12 PM
  • The two ways of doing this is with your allocation enclose it into a try catch block.

    try

    {

        //allocation here

    }

    catch(std::bad_alloc bae)

    {

        //bad allocation handler here

    }

     

    If you want the older no throwing version thoug, link with nothrownew.obj, it is an object in the CRT.

    Saturday, May 12, 2007 4:58 PM

All replies

  • The problem might be that your program is modifying memory that it is not supposed to. Those problems can be difficult to find and are especially difficult to get help with from others that do not study your code extensively. Most people in these forums don't have time available to do that. You need to analyze your code and ensure that indexes and subscripts are never used with values that are out of range. Also ensure that other pointers are valid.
    Saturday, May 12, 2007 9:03 AM
  • Thanks for the reply!

     

    There are no indexes or subscripts, there's just:

     

    agent=new AGENT;

     

    and that's where the problem occurs. Inside the 'new' operator. It's a bit strange that this problem disappears when the same project is compiled with VS 2005.

    Also, is it possible to get VS 2005 express without having to install it from the internet?

     

    Thanks!

    Saturday, May 12, 2007 1:12 PM
  • You don't understand. The error you are getting in new might be a symptom. The actual cause could be elsewhere. The fact that it works using a different version of the compiler might also be coincidental. You might in the future encounter a different symptom using the other version of the compiler. The symptom might be very different eventhough the cause is the same.

    The actual problem might be very different from what I am describing, but based on the evidence provided so far, the possibility I suggest is possible.

    Saturday, May 12, 2007 2:34 PM
  • The reason I say the problem might be that memory is being written to that should not be is because "the error is in the CheckBytes(...) function". My guess is that since it is the CheckBytes function, it is nearly certainly the problem I describe. The purpose of the CheckBytes function is to catch errors such as that.

    Saturday, May 12, 2007 2:38 PM
  • Just to make sure I was clear before: CheckBytes function doesn't catch the error in this case, it crashes.

     

    Anyway, thanks for the replies, I guess it's back to 16000 lines of code for me...

    Saturday, May 12, 2007 3:15 PM
  • If I remember rightly, in 2005 there is a difference in how new reports an error. Instead of it returning null it actually throws an error. So, is the crash you are getting an unhandled exception?
    Saturday, May 12, 2007 4:12 PM
  • Yes. So the version of my program built with 2005 runs even though it made an error?
    Saturday, May 12, 2007 4:39 PM
  • The two ways of doing this is with your allocation enclose it into a try catch block.

    try

    {

        //allocation here

    }

    catch(std::bad_alloc bae)

    {

        //bad allocation handler here

    }

     

    If you want the older no throwing version thoug, link with nothrownew.obj, it is an object in the CRT.

    Saturday, May 12, 2007 4:58 PM
  • The original question says that the exception is an access violation, but not consistently. I think both of those are inconsistent with "new" reporting an error.
    Saturday, May 12, 2007 5:00 PM
  • VS says:

     

    Unhandled exception ... : Access violation reading location ...

     

    this location is a pointer in the CheckBytes function that points to the bytes that have to be checked (bytes for allocation).

    Saturday, May 12, 2007 5:26 PM
  • That means you have a dangling pointer. Maybe you are not allocating the memory to a pointer in the function.
    Saturday, May 12, 2007 6:40 PM
  • Well, I can't do anything about it. When 'new' is used, it calls a number of functions which call other functions. One of those 'other' functions is CheckBytes. In other words, I didn't write it and I didn't give it that pointer as its argument. I'm worried that Simple Samples was right...
    Saturday, May 12, 2007 8:26 PM
  • All you can do is debug, find out where it is going wrong and then fix it.
    Saturday, May 12, 2007 8:56 PM
  • Hopefully I am wrong. Hopefully the problem is easier to diagnose. At least I got you prepared for the worst, but I hope I have not discouraged you from diagnosing the problem.

    I think one thing to determine is if the results you are getting are normal for "new" to do when there is a problem of some type. There are few reasons that cause it to fail; I mean it is unusual as far as I know.

    Saturday, May 12, 2007 11:02 PM
  •  Hilikus wrote:

    Thanks for the reply!

     

    There are no indexes or subscripts, there's just:

     

    agent=new AGENT;

     

    and that's where the problem occurs. Inside the 'new' operator. It's a bit strange that this problem disappears when the same project is compiled with VS 2005.

    Also, is it possible to get VS 2005 express without having to install it from the internet?

     

    Thanks!

    I might have overlooked the cause. It might be a problem in the constructor. Is there a constructor for AGENT? If so, then is it trivial or is there possibly something hiding there?

    Saturday, May 12, 2007 11:04 PM
  • I would just like to know for sure if the problem is in my code. Most probably it is, but if you say that there's a chance that my 'new' crashes with abnormal results...

    And about discouraging me - impossible.

    Sunday, May 13, 2007 10:32 AM
  • No constructor...
    Sunday, May 13, 2007 10:35 AM
  • AGENT doesn't have a constructor.
    Sunday, May 13, 2007 10:37 AM
  • Look in the Debugging Native Code FAQs; there could be a technique to diagnose what is clobbering storage.
    Sunday, May 13, 2007 11:40 AM
  • Thanks, I'll try those...
    Sunday, May 13, 2007 5:47 PM
  • FAQs don't help... And I just discovered another thing. Up until now i was just building the debug versions, and they had the bug. The release versions don't have the bug.
    Monday, May 14, 2007 5:01 PM
  • Note that if the problem is that memory is being corrupted by your program writing to memory it is not supposed to, then it is likely you will feel safe and then eventually get hit by a bigger crash. The function (checkbytes or whatver) is probably only done for a debug build. So perhaps a release build just does not see the problem, but the problem can manisfest later in a release build if it is a memory corruption problem.

    Hopefully you are safe, but don't be so surprised when you get another unexplainable error in a release build.

    Monday, May 14, 2007 7:03 PM