3

Unhandled exception at 0x758cd36f in OSGP.exe: Microsoft C++ exception: std::bad_alloc at memory location 0x0028ef70..

I am trying to execute the code below in Visual Studio. However, i keep running into the exception above. I added a try catch to aid me in catching the error but to no avail it seems. I believe the problem is related to the following from the output window

First-chance exception at 0x758cd36f in OSGP.exe: Microsoft C++ exception: std::bad_alloc at memory location 0x0019f2f4..
First-chance exception at 0x758cd36f in OSGP.exe: Microsoft C++ exception: std::bad_alloc at memory location 0x0019ec84..
First-chance exception at 0x758cd36f in OSGP.exe: Microsoft C++ exception: [rethrow] at memory location 0x00000000..
The thread 'Win32 Thread' (0x16dc) has exited with code 0 (0x0).
The program '[448] OSGP.exe: Native' has exited with code 0 (0x0).**

Here's the code:

#include <osgDB/ReadFile>
#include <osgViewer/Viewer>
#include <new>

#include "stdafx.h"

using namespace std;

int _tmain(int argc, _TCHAR* argv[])
{ 
    int flag = false;
    osgViewer::Viewer viewer;
     osg::ref_ptr<osg::Node> root;
    try
    { 
        root = osgDB::readNodeFile("cessna.osg");
        viewer.setSceneData(root.get()); 
    }
    catch(bad_alloc)
    { 
        if (flag) cout << "a bad_alloc exception just occured"; 
    }
    return viewer.run(); 
}
Captain Obvlious
  • 19,754
  • 5
  • 44
  • 74
user272671
  • 657
  • 4
  • 13
  • 26
  • `osgDB::readNodeFile("cessna.osg");` can return a nullptr if it fails to open the file. FYI assigning a `bool` to an `int` flag that is not ever really used is also a bit silly ;-) – AJG85 Jun 07 '12 at 21:27
  • Most of the output is just the debugger telling you it can't find the program database (symbol) file. – Captain Obvlious Jun 07 '12 at 21:28
  • 1
    Turn on exception breakpoints in `Debug->Exceptions...->C++ Exceptions` so you stop when the bad_alloc is thrown. – molbdnilo Jun 08 '12 at 09:34
  • Only a note: You should catch the exception by a const reference. See [C++ Core Guidelines E.15](https://isocpp.github.io/CppCoreGuidelines/CppCoreGuidelines#e15-throw-by-value-catch-exceptions-from-a-hierarchy-by-reference) – Sonic78 Apr 13 '22 at 07:52

6 Answers6

10

std::bad_alloc is commonly thrown when the program doesn't have enough memory to complete the requested action.

Possible problems:

  • cessna.org too large to be processed on the machine you are running this on
  • bad data/logic in cessna.org causing it to try to allocate an infinite amount of memory

But it is impossible to say with the information given.

Ryan Erickson
  • 731
  • 1
  • 15
  • 23
  • I am able to open the cessna.osg using osgviewer, with no problem , from command line but add code and then run it, I get that exception. I would like to debug it,and this is why I added the try catch, but that has yet to help me figure out what is wrong with that small program. – user272671 Jun 07 '12 at 23:41
  • You wont be able to debug the error as it is happening in OSGP.exe unless you have source code and symbols for OSGP.exe. Also you can have visual studio prompt you when the exception is thrown rather than using the try/catch by going to Debug->Exceptions and add std::bad_alloc as a C++ Exception – Ryan Erickson Jun 11 '12 at 17:25
3

A bad alloc may also get thrown if there's a pointer to invalid memory being passed in an object's constructor.

Robin Rowe
  • 211
  • 3
  • 4
2

I should qualify this response by disclosing that my coding expertise can be generously described as novice.

I had a similar error with some code that I was running. The cause appeared to be when I was declaring a new array like so:

path_chr = new char [path.size()+1];

I was doing this many times (millions?) in my code. It looks like I eventually ran out of memory. The fix was deleting the variable when I was done.

delete [] path_chr;

Never had problems after that.

Ali
  • 21
  • 1
2

Change solution platform x86 to x64. RAM is 16Gb but visual addressing only 4Gb block by x86 Configuration Manager

0

I find that this happens when you try to read past the end of an array.. That is, if you try to access more elements than the number of elements present in the array.

mahela007
  • 1,399
  • 4
  • 19
  • 29
0

I was facing a pretty similar problem for OSG setup; turns out Visual Studio by default will not link Release OSG dlls to your Debug application appropriately. I reconfigured for Release and observed readNode() didn't throw bad_alloc and ran successfully. I believe the permanent solution is to build OSG yourself.