This seems to occur somewhere near the end of the program, but well past any portion I have written. In fact, there are no local variables or context available in any of these frames. I'm working on going back and checking to make sure I'm deleting all my allocated memory, but does anyone have any specific advice about debugging this more precisely?

Thanks for the response. Any idea why these functions are running after my code is apparently finished? If I had some sense of what they were trying to do, and what they might be referencing it would shed some light on the situation.

>Any idea why these functions are running after my code is apparently finished?
There's a lot of hidden framework around your program. Consider destructors as a general example. They run behind the scenes after your code is apparently finished.

> but does anyone have any specific advice about debugging this more precisely?
Use valgrind or electric fence.
These trap out of bound memory accesses at the point of access.

Segmentation faults usually show up when you try and use the corrupted memory for it's original purpose (which is usually much later), and is seldom anywhere near where the actual corruption took place.

gdb has always done the trick for me. I've done a fair amount of network and system level C coding, so segfaults are nothing new. Where I think I'm getting stuck is the C++ memory management framework. My code seems to work, but then crashes when it's cleaning things up (default destructors?) The annoying part is that I'm extending pre-existing code, so it's entirely possible that they did something wrong which only manifests itself with my code. For instance, I'm pretty sure they have memory leaks because I see many new()s without corresponding delete()s.

Anyway, I'll check into those programs to see if they shed any more light on what's going on. Thanks a lot people.