C++ vector debugging
My program crashes after a long run like this:
-- clip --
ERROR!!: vector::_M_range_check
[Thread 0xb6394b90 (LWP 11690) exited]
Program exited with code 01.
(gdb) bt
No stack.
-- end clip --
That clip is from gdb. The question is: how can I trace with gdb where that erroneous indexing of a vector happened? Gdb says "No stack." because the program actually didn't cause a segmentation fault. This is why you should always use [] instead of .at() :)
Quote:
That clip is from gdb. The question is: how can I trace with gdb where that erroneous indexing of a vector happened? Gdb says "No stack." because the program actually didn't cause a segmentation fault.
There are plenty of reasons you could not have a stack trace -- you've compiled without the neccessary debugging information, optimizations have confused the debugger, or you've trampled the stack with bad memory accesses, et cetera.
Unfortunately you have not provided enough information for anybody to really provide that much help. We'll need more context.
Quote:
This is why you should always use [] instead of .at() :)
That likely has nothing to do with it.
Quote:Original post by jpetrieQuote:
That clip is from gdb. The question is: how can I trace with gdb where that erroneous indexing of a vector happened? Gdb says "No stack." because the program actually didn't cause a segmentation fault.
There are plenty of reasons you could not have a stack trace -- you've compiled without the neccessary debugging information, optimizations have confused the debugger, or you've trampled the stack with bad memory accesses, et cetera.
Unfortunately you have not provided enough information for anybody to really provide that much help. We'll need more context.
Oh yes, I have my program compiled with g++ -O2 -g -Wall -pedantic. I'm running Ubuntu 8.04.
Maybe I'll try first without any optimizations.
Quote:Original post by jpetrieIt sort of does. If he had used [ ], there is a good chance that the app might have segfaulted, and then there would have been a nice stack trace. Given that at() throws an exception, and GDB doesn't pause on C++ exceptions by default, he instead gets all the way to program crash due to the uncaught exception.Quote:This is why you should always use [] instead of .at() :)That likely has nothing to do with it.
To remedy this, you need to tell GDB to pause whenever it intercepts a throw expression, which is described in some detail here. Note that there are a couple of issues and restrictions related to this.
Quote:It sort of does. If he had used [ ], there is a good chance that the app might have segfaulted, and then there would have been a nice stack trace. Given that at() throws an exception, and GDB doesn't pause on C++ exceptions by default, he instead gets all the way to program crash due to the uncaught exception.
This is exactly what I meant.
Quote:To remedy this, you need to tell GDB to pause whenever it intercepts a throw expression, which is described in some detail here. Note that there are a couple of issues and restrictions related to this.
This was really helpful! Now I've got a stack trace and I'm able to proceed with the debugging. Thanks!
Quote:Original post by swiftcoderSomewhat off topic, but does anyone know why GDB does not pause on C++ exceptions by default? It seems more than a little odd not to - unless the implementers felt that it was reasonable to use exceptions for general program control flow.
Given that at() throws an exception, and GDB doesn't pause on C++ exceptions by default, he instead gets all the way to program crash due to the uncaught exception.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement