Sign in to follow this  
The C modest god

Serious bug and memory debugging tools?

Recommended Posts

I have a serious bug, because I cant recreate it. However, I assume this bug is inside a certain portion of code. Because everything worked fine before that portion of code and when doing a WinMain with only this portion of code I still got these bugs. However, the problem is that this bug does not always happen. In a matter of fact, the code where the bug appears at, may run perfect many times. What happend is that some class's content all becomes zero for some kind of reason. It may happen in all sort of places in the code. The most weird part was that I was debugging my program, I stopped on a certain command line. Every thing seemed ok, the original class had the proper content. Then I wrote some expression in the watch, and after pressing enter, suddenly the content of the original class changed to zero eventhough I didnt advanced or excecuted a line of code. It changes just after of adding something to the watch. How is this possible? So I want to find tools that track all sort of memory bugs. I heard there is a software called bounderies or something like that. But heard it isnt such good. Do you know of good programs to track memory bugs for visual C++ 2003? Thanks in advance.

Share this post


Link to post
Share on other sites
i'm trying to use insight (which is a gui for gdb) and having very little success determining where my code is having a problem. my biggest complaint is that insight will not let me see the contents of an stl::vector object but rather only the start, finish, and end of storage elements. unfortunately the values displayed even in those elements don't match with what the program is printing to the console (that issue isn't my bug though).

are there any other debuggers out there that don't involve visual studio? i'm using devcpp and the built in debugger is even more crippled than insight.

i'll probably post the issue later if no one is able to suggest a better debugger.

thanks!

Share this post


Link to post
Share on other sites
Quote:
Original post by The C modest god
Have a clue what can cause this?

Probably some form of memory overwrite. Maybe you're hanging onto objects from the stack which are now pointing at different objects. More likely you're overrunning the bounds of an array or similar (char arrays are always favorite).

Such are the joys of C/C++ [grin] If you can narrow it down so that the 'victim' is known in advance then hardware breakpoints can be set to trigger on memory writes which should point you straight at the source. If you can't do that then disabling large chunks of code may be your next best option.

Share this post


Link to post
Share on other sites
Guest Anonymous Poster
Quote:
Original post by supercat1
i'm trying to use insight (which is a gui for gdb) and having very little success determining where my code is having a problem. my biggest complaint is that insight will not let me see the contents of an stl::vector object but rather only the start, finish, and end of storage elements. unfortunately the values displayed even in those elements don't match with what the program is printing to the console (that issue isn't my bug though).

are there any other debuggers out there that don't involve visual studio? i'm using devcpp and the built in debugger is even more crippled than insight.

i'll probably post the issue later if no one is able to suggest a better debugger.

thanks!


Gdb can handle many debugging tasks just fine. For example, if you want to see the contents of a vector, don't type the name of the vector (I don't think many (any) debuggers would showh you the contents of it that way). Type what you want to see, like myvector[0], which will show you element 0. If it's a vector of pointers, type *myvector[0] to se the item that myvector[0] points to. And so it goes.

Share this post


Link to post
Share on other sites
I am trying to use visual2003 data breakpoints and they are completly unusable.
Either they are too slow, or either they dont work. But sometimes they do work.
I tried a data breakpoint on PointsList.Points, and when I tried to step over a line of code, it got stuck on it, which should take a lot faster. When I tried to break to see where it is stuck, it says there is no code for it and I can only see assembly.
It is just a method that do some simple calculations on my classes, doesnt call hardware or anything like that.
This method didnt refer to the class I set the breakpoint on.
Another thing that happened to me, is that a certain breakpoint stopped me every step, where there were no apparent changes to that class the breakpoint was set on.

Is it possible that visual 2003 does not use hardware breakpoints? Like suggested that 2005 does use, in the article?

I didnt completly understand what the context is suppose to refer to, though I used the context it created when creating the new breakpoint in the method the class is a local variable.

Am I doing something wrong with the breakpoints?

Share this post


Link to post
Share on other sites
Guest Anonymous Poster
Quote:
Original post by The C modest god
Another thing that happened to me, is that a certain breakpoint stopped me every step, where there were no apparent changes to that class the breakpoint was set on.


Interesting, don't you think? That might very well have been your bug. Seemingly innocent code overwriting other data because of a stray pointer or buffer overrun...

Either that, or you accidentally placed the memory breakpoint on the stack.

[/quote]
Is it possible that visual 2003 does not use hardware breakpoints? Like suggested that 2005 does use, in the article?
[/quote]

Yes, x86 CPUs support hardware breakpoints - all debuggers I have seen can make use of them.

Share this post


Link to post
Share on other sites
Quote:
Original post by Anonymous Poster
Quote:
Original post by The C modest god
Another thing that happened to me, is that a certain breakpoint stopped me every step, where there were no apparent changes to that class the breakpoint was set on.


Interesting, don't you think? That might very well have been your bug. Seemingly innocent code overwriting other data because of a stray pointer or buffer overrun...

Either that, or you accidentally placed the memory breakpoint on the stack.


Is it possible that visual 2003 does not use hardware breakpoints? Like suggested that 2005 does use, in the article?
[/quote]

Yes, x86 CPUs support hardware breakpoints - all debuggers I have seen can make use of them.[/quote]
Sometimes the breakpoints worked as expected. But many times they didnt work well.
You didnt answer me last question, I wanted to know if visual 2003 always uses hardware. Because the breakpoints are extremly slow when I use them, so I guess it doesnt use breakpoints in that case or either the hardware may be very slow.
The article pointed out something about the speed of the breakpoints and it said there shouldnt be any significant slow down, and I was using only a single breakpoint.
How can I place the breakpoint on the stack? I give it variable names, not address.

Share this post


Link to post
Share on other sites
now, i was not trying to suggest that gdb can't do what i need, because it obviously is used quite a bit. however, what i was saying is that i really don't know how to use insight and that dev-cpp's debugger is broken.

what i mean by "don't know how to use" is that when i try to do as you suggest (type in the actual element i want to check) i receive errors that say "One of the arguments you tried to pass to operator[] could not be converted to what the function wants." and i only put in "testobj.materials[0]" as what i wanted to see (the first element in the vector). and that was it, not further information on why passing in an int to the operator[] failed. pretty bizarre and unhelpful. do you know of any other gdb guis for windows other than insight?

Share this post


Link to post
Share on other sites
Quote:
Original post by The C modest god
Because the breakpoints are extremly slow when I use them, so I guess it doesnt use breakpoints in that case or either the hardware may be very slow.
The article pointed out something about the speed of the breakpoints and it said there shouldnt be any significant slow down, and I was using only a single breakpoint.
How can I place the breakpoint on the stack? I give it variable names, not address.

'hardware' breakpoints doesn't refer to the speed of operation (ie. not like a 'hardware TnL') but their capability. Hardware breakpoints require support at a CPU level in order to support additional features (like breaking when memory addresses are read and written too). Software breakpoints (done by scattering special instructions along with the regular code) will only let you halt execution when it reaches that particular point in the code.

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