Sign in to follow this  
riserbar

C++ vector debugging

Recommended Posts

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() :)

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
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.



Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
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!



Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

Sign in to follow this