IMO, that's not a bad question. C++ is not my thing, but I don't see anyone mentioning.

A) Running the code on another system to double check that the systems memory / OS has not been corrupted. I once wasted ~6 hours on a corrupted production box, so now the new rule is when system call fail double check it's not just the machine.

B) Double check that none of the memory allocation / book keeping memory had been over written, memory had not been freed twice etc.

Honestly, I usually try to do that type of stuff by direct code inspection. If it's failed once I am probably going to need to debug related code in the not to distant future so really understanding what's going on is important, but hack and slash debugging can be fun.

Since we're chiming in on possible solutions, why not do the most general thing first? Check memory usage of the system and process right before segfault, check environment variables that govern malloc behavior (i.e. MALLOC_OPTIONS, OS X-specific ones), check if using (s)brk() system call succeeds right before that, check ulimits.

Then you can either litter break points and start stepping or load the core file in gdb, and start looking closer.

This feels like kind of a cheap answer, but I know that with Visual Studio you can step into most standard library functions, even if it ends up being at the assembly level; I assume the same is true for gdb.

Is the not asshole answer to be stopping right before the malloc and taking note of memory consumption and determining how much malloc is trying to allocate?

Run the program under valgrind.

I'd start logging all the previous calls to malloc/free?