[flaub]

For me, I've always thought that the 'greatest developer' was really the one that was the greatest at debugging. Any developer can write code, but my experience has shown that only a subset can properly diagnose issues to find their root cause. Those on the team that can do that will save you huge amounts of time and money because things will go wrong (especially in C++).

If you add up all the time it takes to write a particular system, I think you'll find debugging and fixing bugs to be one of the largest chunks of time, probably beating out the time it actually took you to write and possibly design the system. Obviously a design more suited to maintainability will decrease this somewhat.

Given this, I'd say this is an excellent question. Especially if the interviewee can tell you why it's a bad idea, or what the gotchas are with using 'delete this;'. It might not find developers with other positive characteristics like what makes for simple and elegant designs. But if you have a mix of questions to cover the many aspects of development in the interview, you should be good to go.

[tptacek]

Standard C/C++ interview question for me for the past few years: "how would you go about debugging a program that segfaulted inside of malloc".

[Retric]

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.

[yan]

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.

[onewland]

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?

[tptacek]

Stepping through malloc isn't going to help you much in this case. But most people I've met that have written a lot of C/C++ code have seen this bug at least once.

When you start asking about how much memory malloc is asking for, that's a tip-off in the wrong direction for me too; malloc handles "out of memory" pretty gracefully.

[kscaldef]

Run the program under valgrind.

[tptacek]

CHEATER!

[chris100]

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

[tptacek]

You would then be buried under an avalanche of log lines, but then I'd just ask "what are you looking for?".