How to backtrace an assertion failure?

Question

If an assert() fails during the execution of the program, there doesn't seem to be any way of backtracing the function call stack up to that point. If I open the console from the 'Run' menu and try to write 'bt', it doesn't let me. gdb seems to be in a strange state where you can write just one character and then it's stuck until you press return, after which nothing happens. Backtracing works ok if eg. the program crashes with a segmentation fault, but it doesn't work if it crashes with an assertion failure.
This is extremely irritating. I have a bug in my program which is causing an assertion failure very, very rarely (making it extremely hard to reproduce), and in the very rare occasions where it's happening, I can't find the exact chain of function calls leading to that failure because xcode won't let me backtrace. (And no, the file/line where the assertion failure is happening, which xcode is reporting, is not helpful in this particular case because it's being called from many different places.)

Answer 1

Is it even possible to do any other type of programming for the iPhone than Cocoa Touch?
Anyways, I cannot control all instances of assert() being called because some of them may be coming from the gcc C++ standard library implementation (mainly when GLIBCXXDEBUG has been defined). Rather obviously, when that happens, a backtrace would be really useful to see exactly which line caused the assert() inside the library to fail, especially if it happens inside a library function not directly called from my code (but by other library code) and/or when it's called from very many different locations in my code.
But it's not just a problem with an assert() failing inside the C++ libraries. Any assert() in my own code causes the exact same behavior, and sometimes it's rather irritating not being able to get a backtrace, especially if it happens extremely rarely and thus is very hard to replicate. This even when building in debug mode.