Sign in to follow this  
dave

How should i test my memory manager?

Recommended Posts

This may seem like a very vague topic and dont get me wrong, i have tried testing it in as many ways i can think of, but there is something about the SDK examples that cause me problems. The overview This memory manager allocates a large pool at application start up and then makes sub allocations depending on the new and delete calls that are made by the application it is running in. Now i have tested this memory manager on numerous applications and it passes all of them. It works for all of the DirectX 9 SDK tutorials, several of my own applications and several of other peoples. I have written unit testing for it that tests the following: 1) Bad initialisation of the memory pool. 2) A pool of zero size. 3) A pool of non-zero size but isn't big enough for allocations. 4) A test for making random amount of allocations of random size and then deleting them in a random order. Also a couple of other less crucial tests. The Crunch At this point i was pleased with my manager, all was going well. I thought that the next thorough test would be to patch it into the SDK examples. It fails at the first example, Blobs. For some reason it crashes after the return statement of WinMain(). Everything appears to allocate fine because the application runs flawlessly. However, it's when the application exits i get the problem. The only information i have on the matter is that it crashes when a getter function is called in a class named CGrowableArray, which i believe is a component of DXUT. Now i dont see any reason for it to crash in this program when it doesnt in the others. All i can think of is that there is some tricky concept of the way things are allocated and freed that i am unaware of and that the other test programs didnt make use of, for what ever reason. What i am asking for If you were to test this memory manager with some unit tests, what would you do on top of what i have already tested. There is something i have missed. If you have the time, maybe some of you could post code or links to some source of full applications you or others have written that i can test it on. Thanks for any input, Dave

Share this post


Link to post
Share on other sites
Well what does that class do that your test cases don't?

And some code showing what your memory manager replaces would probably be good...

Share this post


Link to post
Share on other sites
I don't know what that class does.

On a slight side note, i worked up a theory that it was something to do with the D3DX extensions, but i think it is something to do with DXUT. I have just run my memory manager with my renderer, this makes heavy use of D3DX and it has no problems.

Must be D3DXUtil.

Dave

Share this post


Link to post
Share on other sites
Since you didn't tell us what the problem was which you actually found,
I'm going to take a guess.. :)

With memory-managers, one interesting mistake is if an sdk uses a 'new'
inside a header and the delete in the cpp (or the other way around) (
one version of libsigc++ does that).

Then when compiling it uses your overided allocation/deallocation function
for the one in the header but the default one for the one in the cpp - which
is a problem if your memory manager does sth like add a few bytes before each
allocation to check for memory overwrites.

You might keep a list of things which your manager allocated - and on
freeing, double-check if it was a block which you actually allocated.

Maybe you can also add a testunit for some random allocations/deallocations.

And I would also definately profile how quick your manager is - last
time I tried some pooling mechanism, the vc7.1 default implementation
beat mine by a (very) small margin - so there is something like a 'small
block heap' for small allocations I guess :)

Share this post


Link to post
Share on other sites
Hey,

The problem was that i was simply cleaning up the pool without allowing all of the classes to destruct first, which simply meant that they crashed.

Last time i profiled it was much quicker than the Release run-time. Take that with a pinch of salt though as it was a while ago and i havn't tested it on this one.

Dave

Share this post


Link to post
Share on other sites

>The problem was that i was simply cleaning up the pool without allowing
>all of the classes to destruct first, which simply meant that they crashed.

Easy to make a testcase for that - throw an exception (or assert or whatever),
when you find that you are still managing memory which hasn't been released
by the app (also good for finding memory leaks!)

Regards

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

Sign in to follow this