So I'm trying to get the best, most fully-featured C experience on Windows (10) and I come from C# development so I am used to Visual Studio. However, I didn't really like having to essentially use Visual Studio's C++ environment to develop C. For example, I was having serious input buffer issues and when I switched to Code::Blocks that all stopped.

That said, of course as a C newbie, I'm chasing some nasty memory bugs around and on the stream, Casey showed some very powerful stuff for doing this on his Intro to C on Windows tutorials but they are Visual Studio. It appears as though Casey is actually developing from a C++ environment but only using C, however, I have had people tell me not to do that because there can be conflicts and such.

That said, if you HAD to develop in C on Windows (like I do), what is the best IDE and best way to hunt down memory issues? I am open to whatever suggestions you have.

Of course in C#, I would throw down breakpoints, and exceptions such as a NullReferenceException would be thrown when I did something like try to use an "object" that was not yet instantiated.

Some things I have tried in Codeblocks is I was able to get the below output for the program (pictured) which basically says the memory I am trying to access is not accessible but it is somewhat strange as the only thing that has happened between when the memory was accessible to when it is not, is that a function was called, even though the pointers are indeed global.

Anyway, the point of this post is not this specific problem, but rather any tips you have, IDE, or otherwise, to squash memory-related bugs on Windows? Mainly because I feel this will be the hardest part for me coming into C from languages such as C# and JavaShit. Erm... Did I say that??

Thanks.

There is no "one size fits all" solution for memory errors troubleshooting in C, it mostly depends on the problem at hand: the data structures, code flow, allocation/deallocation pattern, whether is heap memory or stack memory, etc...

For your particular case, you are lucky to have the program crash on the error :), so what you can do is check the value of the _counter_ variable when the crash happens. Then, using a condicional breakpoint, stop the program a few iterations before the crash (one might be enough) and inspect the variables at that point. You'll probably see that the _currenta->next_ is pointing to the memory location that makes the program crash. So the question is: why is that value there? Did you forget to set the next pointer to 0/NULL to signal that the list is finished?

Hope that helps!

I normally debug with VS, but I've found that it doesn't always make memory bugs apparent.

In those circumstances I've used Dr Memory (http://www.drmemory.org/), which I believe is somewhat similar to Valgrind on Linux. It's definitely helped me spot some bugs that I don't think I would have otherwise (bear in mind I'm still a pretty inexperienced programmer).

If not using the command line, you can just drag your exe onto drmemory.exe (or the other memory analysis tools included). If your exe requires arguments, you can use a shortcut with the arguments in the 'Target'.

azmr
In those circumstances I've used Dr Memory (http://www.drmemory.org/), which I believe is somewhat similar to Valgrind on Linux. It's definitely helped me spot some bugs that I don't think I would have otherwise (bear in mind I'm still a pretty inexperienced programmer).

Nice catch, dude

I've been looking for a valgrind equivalent on windows for quite some time now, and faced only frustration using Very Sleepy or similar profilers. Will give this one a go soon enough, I hope. Thanks for the rec!

One of the thing that I've seen Casey do is put assignments that return pointers in if controls with empty else statements. I replicated this when I was implementing DirectInput interfaces in my platform layer and was constantly getting crashes, usually on Windows, but not in WINE (Linux SDL platform was irrelevant).

If you initialize all your pointers to zero before assignment, and wrap all the places where assignment returns pointers, just put printf's or DebugOutput's in the else blocks that say "Allocation for X pointer failed" where "X" is the address of the object you expected.

Another cool part of building on three platforms at the same time, is stuff that breaks usually doesn't break everywhere. Gives you really good insight to the problem even before opening a debugger. Usually, I debug on Linux with gdb and that's it. I almost never have to monkey with it on Windows, since VS will usually go directly to the failed line when you open it.

At some point, I'll have to see if there is a console equivalent of the VS debugger.

k2t0f12d
At some point, I'll have to see if there is a console equivalent of the VS debugger.

It's called windbg. It has gui (windbg.exe), and also console debugger - cdb.exe.

mmozeiko
It's called windbg. It has gui (windbg.exe), and also console debugger - cdb.exe.

That's awesome. The next time I have a bug in my code running on Windows, I will definitely check that out.

Thanks for all the tips everyone!!! Meanwhile, I also switched back to Emacs and am loving it! With a little practice, I am by far faster in Emacs than any IDE and it's so much more fun/powerful/fast to just use cmd/emacs! I'm gaining some more experience with GDB and next stop will be Dr. Memory and the tools/tips mentioned above!

@k2t0f12d have you tried gdb on windows?