What are your best debugging strategies?

Question

I have to upload a project today and while uploading it is tested, but the test always fails at some point, because I have some memory leaks probably and I can't find them.

Do you have any advice on a good debugging strategy? How do you debug your code?

Answer 1

if u have leaks it is probably pointers that arent getting deleted. For every new there should be a delete. I would start there.

Here is a post on stack overflow that may help.

http://stackoverflow.com/questions/6261201/how-to-find-memory-leak-in-a-c-code-project

Answer 2

Hm well if you have code analysis on it will tell you where your memory leaks are. (for VS anyway) These links might help:

https://msdn.microsoft.com/en-us/library/x98tx3cf(v=vs.140).aspx

https://msdn.microsoft.com/en-us/library/dd264897.aspx

Answer 3

aklex = good advice. +5 for you if I could

Answer 4

getting a bit O/T isnt us. We can all agree smart pointers are a good idea can't we? As I think that is the main point of the original question. (or most likely cause of the leaks as you will)

STL containers are the way to go as they were made for a reason. To make life easier. If managed correctly normal arrays are fine.

Both have a place.

But as a new programmer I see the benefit to having stuff managed for me. Cause you know. Lazy.

Answer 5

@jay, yes they both have their uses but lazyness is not an excuse. Expert programmers like the one made the Quake series can squeeze out as much performance if not more than what the STL can do. Everything he did was coded in C. He later changed to C++ but didn't use the STL, and the games are blazing fast when it comes to loading data. Especially since game engines are usually data driven.

Answer 6

Containers might be too slow for certain purposes though. I have a 3d engine that loads Quake 3 maps and I thought that vectors would be fast enough to load vertices and face data, but I found out that it's painfully slow. So I reverted to arrays....

Answer 7

@Aklex, yes I'm sure. Vectors are fast to access but push_back is slower than incrementing an array. Also vectors consume more memory.

Answer 8

@aklex. I simply mean incrementing an array index and assigning a new object. And you need to use push_back if you use vectors, although I did some research on this and apparently the reserve() function used before push_back makes them somewhat faster. At least according to some sources.

Answer 9

indeed. not to mention embedded hardware. But you know. Not many experts around here

Answer 10

If you are having memory leaks then you are probably not using the standard library as you should be. Instead of dynamic arrays, use STL containers like std::vector. Instead of raw pointers with new and delete, use smart pointers like unique_ptr or shared_ptr which automatically delete the object they are pointing to when they go out of scope or when they are no longer being used. There is plenty of RAII stuff in the standard library to prevent memory leaks and other issues.

Answer 11

@aklex we are not allowed to use the standard library and can only use raw pointers 😅 If we could use all this, life would be much easier

Answer 12

But anyways thanks for the advice, so actually I found the mistake, it was because I didn't use the correct size for the for loop and therefore, some items at the end of the table weren't rehashed and I lost them

Answer 13

yeah one line at a time is good but so time-consuming especially if there's hundreds of lines of code

Answer 14

@jay thanks!

Answer 15

@Helio STL containers are highly optimized and have the same performance if not sometimes faster if you use them correctly. Are you sure you were using the vectors correctly? My opengl engine uses them and Ive never had any performamce issues with them

Answer 16

@Helioform What do you mean incrementing? You cant increment an array normally, you have to create a new array buffer. Push back is slow becuase it allocates more memory and copies it over. But you dont ever need to use pushback if you know what the size is going to be before hand by counting