C++ vector debugging

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 jpetrie 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.

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 jpetrie Quote: This is why you should always use [] instead of .at() :) That likely has nothing to do with it.

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.

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 swiftcoder 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.

Somewhat 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.