Original Post
🔒 Locked
C++ debug tools
Advertisement
The simplest option is to enable Page Heap Mode but it does require plenty of spare address space (link with /LARGEADDRESSAWARE if it's a 32-bit program to double available address space when run on 64-bit Windows).
You could also try http://www.drmemory.org/ but it's not so easy to use.
You could also try http://www.drmemory.org/ but it's not so easy to use.
The simplest option is to enable Page Heap Mode but it does require plenty of spare address space (link with /LARGEADDRESSAWARE if it's a 32-bit program to double available address space when run on 64-bit Windows).
You could also try http://www.drmemory.org/ but it's not so easy to use.
Do these work when the "out of buond" is inside the programs memory?
What kind of allocation is being indexed? Is it created with malloc or new? Is it a member of a class with members on either side? Is it a container class that you've got the code for? Is it a standard container like a std::vector?
For structures that you allocate with malloc/new, most games I've worked on have had a [font=courier new,courier,monospace]#define[/font] that you can enable, which pads every new/malloc call with a begin/end buffer, so that you can watch the buffer areas for corruption. I guess your project doesn't have an allocator with debugging features like this?
There's some good tips in this blog post, including the above mentioned Page Heap mode:
http://randomascii.w...h-more-crashes/
For structures that you allocate with malloc/new, most games I've worked on have had a [font=courier new,courier,monospace]#define[/font] that you can enable, which pads every new/malloc call with a begin/end buffer, so that you can watch the buffer areas for corruption. I guess your project doesn't have an allocator with debugging features like this?
There's some good tips in this blog post, including the above mentioned Page Heap mode:
http://randomascii.w...h-more-crashes/
Page Heap puts each allocation on its own 4-KB page, with the allocated memory aligned to the end of the page. Therefore if you overrun the buffer you will touch the next page. Page Heap ensures that the next page will be unmapped memory so you get a guaranteed access violation at the exact moment that you overrun the buffer.[/quote]
Thanks! Im allocating with new. I have at least 100 classes in this project(and many many allocations)so I dont know where is it coming from, ...the program doesnt crash, no segmentation fault or anything, ....it overwrites some of the object geometry. But I cant reproduce this "error" in debug mode. On an other forum they said thats because in that mode the heap is allocated differently or something.
Is it always the same piece of object geometry that gets overwritten?
If so, assuming you're using Visual Studio, you can set a break point that is triggered when a particular piece of memory is modified. The call stack at that breakpoint will give you the culprit.
A better way, imho, is to start adding more assertions and/or tests.
If so, assuming you're using Visual Studio, you can set a break point that is triggered when a particular piece of memory is modified. The call stack at that breakpoint will give you the culprit.
A better way, imho, is to start adding more assertions and/or tests.
Topic Locked
This topic has been locked by a moderator. New replies are not allowed.
Sign in to reply to this topic.
Advertisement