[NOT A BUG AFTER ALL] std::bad_alloc exception in ...

[Josh1billion]

Here's an exception that's being thrown when I'm calling addAnimatedMeshSceneNode() in Irrlicht 1.6. The same code worked in Irrlicht 1.5, so I'm not sure what the problem is.

The code:

Code: Select all

node = smgr->addAnimatedMeshSceneNode(smgr->getMesh(strMeshFilename.c_str()));

(note: I debugged to ensure strMeshFilename is at the value that it should be, so that is not the problem)

The exception:

Code: Select all

Unhandled exception at 0x7c812afb in Stealth Prankster 2.exe: Microsoft C++ exception: std::bad_alloc at memory location 0x0012f234..

[CuteAlien]

Are you sure you don't mix versions? Check the output on start if there are any warnings about wrong dll versions.

[Josh1billion]

Check the output on start if there are any warnings about wrong dll versions.

I don't see anything about that, but where exactly would it be if so? I'm using Visual C++ 2008 Professional and it's not in the Debug output window pane.

Here's some of the output from that window pane to make sure I'm looking in the right place. Also, I've bolded a line that looks like it has an interesting connection to this exception.

'Stealth Prankster 2.exe': Loaded 'C:\WINDOWS\system32\setupapi.dll'
'Stealth Prankster 2.exe': Unloaded 'C:\WINDOWS\system32\setupapi.dll'
'Stealth Prankster 2.exe': Loaded 'C:\WINDOWS\system32\ksuser.dll'
Using DirectSound8 driver
HEAP[Stealth Prankster 2.exe]: Invalid allocation size - CCCCCCCC (exceeded 7ffdefff)
First-chance exception at 0x7c812afb in Stealth Prankster 2.exe: Microsoft C++ exception: std::bad_alloc at memory location 0x0012f234..
Unhandled exception at 0x7c812afb in Stealth Prankster 2.exe: Microsoft C++ exception: std::bad_alloc at memory location 0x0012f234..

edit: Nevermind, I see where you're talking about now (in the console window). Working with Java and ActionScript for so long makes me forget about output in the console window.

Warning: The library version of irrKlang (1.1.0) does not match the version the
application was compiled with (1.1.2). This may cause problems.

irrKlang.. but not Irrlicht.. so that shouldn't be a problem, I think. I'll have to see about fixing the irrKlang problem anyway, but I don't think it's related.

Any other ideas?

[Josh1billion]

Anyone?

[CuteAlien]

Do the examples work?

I think it's somewhat unlikely that Irrlicht is responsible for a std::bad_alloc as Irrlicht does not even use the STL.

Did you debug it? For example there is a lot of stuff going on in a single line. Distribute it over several lines using a few local variables to make debugging a little easier.

Without more info we can't really do much.

[vitek]

I think it's somewhat unlikely that Irrlicht is responsible for a std::bad_alloc as Irrlicht does not even use the STL.

All that Irrlicht would have to do would be to invoke operator new (which it does quite frequently). That function is supposed to throw a std::bad_alloc exception on failure.

Travis

[CuteAlien]

Hm, ok, Vitek is right as usual. Seems like you get that part of std by default.

I googled a little around and typical reasons for std::bad_alloc seem to be often either a stack-overflow or a messed up stack. So maybe check if the stack looks strange like repeating for example endless the same calls due to some recursion.

[vitek]

Warning: The library version of irrKlang (1.1.0) does not match the version the
application was compiled with (1.1.2). This may cause problems.

irrKlang.. but not Irrlicht.. so that shouldn't be a problem, I think. I'll have to see about fixing the irrKlang problem anyway, but I don't think it's related.

It is very possible that this could be the cause of your problems. If irrKlang 1.1.2 isn't binary compatible with irrKlang 1.1.0, that can cause stack or heap corruption. The library is telling you that you're doing something wrong, and you're just ignoring it. That would be the first thing I'd look at.

You should be able to use the debugger to stop at the instant the exception is thrown. With that, you should be able to get a stack trace, and you should be able to inspect variables to see why such a huge allocation is being requested.

Travis

[Josh1billion]

It was the irrKlang library version inconsistency after all. Thanks for your patience, guys.