bad_alloc in detail?

I work on a game project. Recently, we run into a problem which we catch a "bad_alloc" exception when we load/unload different scenes for about three times.

Eachtime we load a scene, we first load the compressed .zip folder into the memory and then extract game objects from it. Since we don't have any memory profiler tool, I simply use the performance graph of Process Explorer to see what is going on:

1. Run the game ==> ~620 MB
2. Load the 1st scene ==> ~1.1 GB
3. Unload it ==> ~620 MB
4. Load the 2nd scene ==> ~1.1 GB
5. Unload it ==> ~620 MB
6. Load the 3rd scene ==> bad_alloc

I trace down to the new operator of 开发者_如何学Pythoneach load. The loading of the compressed folder costs 100~120 MB memory itself, and the bad_alloc is throw from it at the 3rd load.

Our platform is installed with 2GB physics memory. It seems that we do not left anything behind after unloading the scene. Each compressed folder is about the same size. However, the new operator of the 3rd load just doesn't work.

I'm wondering, what's the possible meaning of this bad_alloc? Out of memory? or simply can't allocate a contiguous block of the required size? If it does have several possibility, how can I determine it?

Any help is apppreciated, thanks!

If you are allocating all that memory at a time (only one new), probably the heap is too fragmented to find enough contiguous memory to allocate what you requested.

That could be solved by allocating the new scene by parts.

bad_alloc is thrown by new when the allocation could not be fulfilled. Likely, you've simply run out of memory. Typically, custom memory managers will also throw bad_alloc when they request cannot be fulfilled, but you said you aren't using any. Run your code in a debugger to see where the exception originates from.

By the way, that's a lot of memory. Most professional games require half to a quarter of what you're doing; look into ways of reducing memory usage. Another thing to watch out for is memory leaks; if you never free memory, you'll eventually run out.