none
This application has requested the runtime to terminate it in an unusual way

    Pregunta

  • Yes, this is only the 1000th time this question is being raised on these forums and not one answer helps, and it is a shame that the only support aritcile available on this error message is a totally irrelevant <cite>support.microsoft.com/kb/884538</cite>

    My application is failing to allocate a large chunk of memory due to fragmentation, and the control goes to my exception handling for bad_alloc. After the exception handling, when I hit continue, it is crashing with the above error. Note that the new operator failed only because of the the large chunk requested, there is enough total free memory so some other smaller allocations (if any, which I'm not sure if they are, since there is 3rd party code involved) cannot cause yet another exception.

    Please help me with why this is happening before I shoot myself. And please delete the Kb article 884538 for the sake of the world.

    miércoles, 27 de julio de 2011 12:33

Todas las respuestas

  • Is this happening when running under the debugger?

    I usually see this whenever a C++ exception is thrown but not caught (and the debugger is not running).  If I attach the debugger, it is much more helpful as it tells me what exception is thrown, and if there is no handler, Visual Studio will break at the point of throw.

    miércoles, 27 de julio de 2011 13:47
  • Yes it happens when running under the debugger. I had earlier set an interrupt statement and launched the debugger.

    Previously the bad_alloc exception was uncaught. Back then at times it used to display this garbage error message that is the header of this thread (with no stacktrace in the debugger), and at other times, it would properly say that bad_alloc had occured. So then I caught the bad_alloc and handled it. Breakpoint hits in the catch clause, but once I hit continue, it displays the good for nothing error message.

    miércoles, 27 de julio de 2011 14:43
  • In debugger, have you enabled "Break on exception" to see where the exception originates? (go to Debug, Exceptions and check C++ Exceptions).
    miércoles, 27 de julio de 2011 15:08
    Moderador
  • Use a memory pool to avoid fragmentation -- dodge the whole issue.

    miércoles, 27 de julio de 2011 15:22
  • In debugger, have you enabled "Break on exception" to see where the exception originates? (go to Debug, Exceptions and check C++ Exceptions).

    I tried this. There is no change in the behaviour. After breaking at the catch clause for bad_alloc, when I hit continue, it simply shows the dialog box with the same message This application has requested . . .
    Why does it have to crib like this just because a large memory alloc failed? I'm sure smaller allocations can still happen. Does it maliciously corrupt the whole heap regardless of whether the exception is caught or not?
    miércoles, 27 de julio de 2011 17:45
  • " it simply shows the dialog box with the same message This application has requested . . ."

    That's unusual, normally you don't get this message if a debugger is attached, it just breaks into the debugger.

    I guess an alternative is to use the non throwing version of new and check for a null return instead of catching bad_alloc. But that might just mask the real problem.

    miércoles, 27 de julio de 2011 18:09
    Moderador
  • For reference I don't know for sure that this is an unhandled C++ exception.  I was just stating that the I only see that message when a C++ exception is unhandled and no debugger is attached.  There may be other situations that could trigger that.
    miércoles, 27 de julio de 2011 18:22
  • Imagining that the weird behaviour may be because the debugger is attached to it, I removed the interrupt statement and ran it normally without launching the debugger. It crashed with the dialog box with the same error message, and after I clicked OK, it popped up the Debug/Abort/Retry window. When I clicked on Debug it launched the Visual Studio, but it seemed to have just crashed away, because it did not open any debugger session. It was like I just opened Visual Stuio for development purposes.

    Rant: How do Microsoft Development tools sell? It is a miracle.

    jueves, 28 de julio de 2011 6:07
  • Hello, what should I do? Can I talk to some MS developer responsible for this component on phone? This is a stupid stupid bug and it is intolerable.

    PS: Is the Program Manager that didn't recruit me after performing so well managing this particular group? Seems like that.

    PPS: He is bald and works in Hyderabad in Bing group, and knows nothing other than some puzzles he dug out of somewhere.


    lunes, 01 de agosto de 2011 14:05
  • Have you tried the nothrow suggestion? Probably not, you seem to be busy ranting.
    lunes, 01 de agosto de 2011 16:01
    Moderador
  • Have you tried the nothrow suggestion? Probably not, you seem to be busy ranting.


    I just tried the nothrow new operator. If it returned NULL I raised an interrupt to know that it has happened. But it simply crashed with the same error "This application has requested..." meaning that the new operator did not even bother to return NULL but somehow crash alone occurs promptly. Don't even know where it is occuring. Is it like the Windows OS pitches in and kills with no explanation the process that is growing too much in memory? Some global allocation strategies overriding local allocation strategies?

    miércoles, 03 de agosto de 2011 11:30
  • "But it simply crashed with the same error "This application has requested..." "

    That's odd. I guess you should try to provide some more details:

    1. what version of VS and Windows are you using?
    2. the lines of code that allocate memory and try to handle the error

    "meaning that the new operator did not even bother to return NULL but somehow crash alone occurs promptly"

    Maybe the heap got previously corrupted... but read bellow.

    "Is it like the Windows OS pitches in and kills with no explanation the process that is growing too much in memory? "

    It doesn't sound like the OS is killing the process, the abort/retry thing usually means you hit an assert. Normally the OS asserts only in checked builds.

     

    miércoles, 03 de agosto de 2011 12:41
    Moderador
  • "But it simply crashed with the same error "This application has requested..." "

    That's odd. I guess you should try to provide some more details:

    1. what version of VS and Windows are you using?
    2. the lines of code that allocate memory and try to handle the error

    I'm using Visual Studio 2008 on Windows 2003 server. My code is very simple:

    logmsg("\Before calling new");
    char* pTmp = new (nothrow) char[m_nMaxSize];
    logmsg("\nAfter calling new");
    if(pTmp == NULL)
    {
    _asm int 3;
    throw bad_alloc();
    }
    IASSERT(pTmp);

     


    I have not yet really written the code to handle the memory alloc failure case, because the crash "This application . . . " happens without the interrupt statement getting fired. Sometimes the interrupt statement get fired. If I handle this also I'm afraid the crash "This application..." will still happen, like it did when I was catching and handling the bad_alloc thrown by new before.


    miércoles, 03 de agosto de 2011 18:14
  • I've tried to reproduce your problem using VS2008 without success. One possibility is that something in your app has set a "new handler" (http://msdn.microsoft.com/en-US/library/5fath9te(v=VS.90).aspx) and that one is doing something like an assert. The best thing you can do is to execute the code step by step inside new's code to see where does it crash/assert/whatever it is doing.
    miércoles, 03 de agosto de 2011 23:31
    Moderador
  • The best thing you can do is to execute the code step by step inside new's code to see where does it crash/assert/whatever it is doing.

    The last of all things tryable is also striked out, because I already put a log statement before and after the call to new. When the crash happened, the last log statement was "After calling new".
    jueves, 04 de agosto de 2011 6:06
  • " because the crash "This application . . . " happens without the interrupt statement getting fired"

    "When the crash happened, the last log statement was "After calling new"."

    Are you telling me that the crash occurs in these lines of code?!

    if(pTmp == NULL)
    {

    Because that's all that's left between logmsg and int 3.

    jueves, 04 de agosto de 2011 6:19
    Moderador
  • Ok, now I actually wrote the code to handle the alloc failure to prevent future allocations. Here is the code

    void HTTPResponseBuff::grow()
    {
     if(m_noalloc) return;
        if (m_nMaxSize > m_nStartConstGrowSize)
            m_nMaxSize += m_nConstGrowSize;
        else
            m_nMaxSize = 2 * m_nMaxSize;
        logmsg("\nCalling new");
        char* pTmp = new (nothrow) char[m_nMaxSize]; 
     logmsg("\nAfter calling new");
     if(pTmp == NULL)
     {
      m_noalloc = true;
      _asm int 3;
      return;
     }
        IASSERT(pTmp);

        //copy the data over
        memcpy(pTmp, m_pBuf, m_nCurrentSize);

        //delete old buf
        delete [] m_pBuf;

        m_pBuf = pTmp;
    }

     Now the behaviour is different. After running the program for sometime, the new operator returns NULL, and after I hit continue, it gives an "Access violation exception" in msvcr90.dll. Disassembly shows the line

     7855AB78 rep movs dword ptr es:[edi],dword ptr [esi]

    I believe this Access violation was what shown as the dialog box "This application..." before, and now due to repeated prayers it has become somewhat kinder. I will rebuild the dlls in the below stackframes with debug symbols enabled and try to find out what line in my code is causing this.


    jueves, 04 de agosto de 2011 6:30
  • "7855AB78 rep movs dword ptr es:[edi],dword ptr [esi] "

    Interesting, that's memcpy code.

    jueves, 04 de agosto de 2011 6:52
    Moderador
  • "7855AB78 rep movs dword ptr es:[edi],dword ptr [esi] "

    Interesting, that's memcpy code.


    And disgusting as well, isn't it. Why would it happen there? I had upgraded to a newer build system and had not faced the crash for all these days, and suddenly it again crashed once again at the memcpy code. My code does have the memcpy following the new allocation, as shown in my earlier post. Please advice how to solve this problem.

    martes, 09 de agosto de 2011 17:26
  • "Why would it happen there?"

    Hmm, you need to look at the callstack to see who called memcpy. Interestingly, your grow function calls memcpy but after checking for NULL. Unless you run into a compiler bug that messes up the code it cannot be that memcpy.

    And something that might be useful to know: is there any threading involved?

    martes, 09 de agosto de 2011 17:35
    Moderador
  • We cannot see here how m_pBuf is allocated initially, and the valeu/handling of m_nCurrentSize.
    Assuming it starts with m_nCurrentSize=0 and m_pBuf=NULL, it will crash because it will copy from a NULL ptr.
     

    I suggest writing some unittests for this class.

    Rob (also bald, no gun)
    www.robtso.nl

     

     

     

     


    miércoles, 10 de agosto de 2011 7:00