tools for debugging win32

Hello all,

I'm just wondering if there's any tool to detect something like gdi leaks, memory leaks and such for programming in windows. I notice windows task manager actually shows how many handles the system are using, and info such as memory used, but it's not too detailed to figure out what handles the program are using etc..

Someone on this forum (can't remember who, sorry) pointed winspy++ to me. I was wondering if theres any programs of the like.

It's just that in linux, you can use valgrind to do memory leak detection. And in linux, theres bounds error checking for gcc (which was veery useful when i was developing my assignments on it).

But then in windows, whenever it crashes, all I get is a dialog box asking for "send error" message. Understanding the error report is impossible for me, and I have no way of knowing what's happening.

So yeah, I really do think i'm missing something.

Cheers

Also, what other free compilers are there that supports win32 programming?

I'm getting this in mingw:

Code:

---

  ct->freed = 1;
  free(ct);

---

and then, later,

Code:

---

  win32assert(!ct->freed, "already freed");

---

The assert code actually found ct->freed to be 1, even though it was supposed to be freed already. This is supposed to be impossible since at construction, freed is set at 0, and as soon as freed is set to 1, the ct struct is freed.

Could this be because of multithreading? Or is this the compiler's error? Or am I missing something?

edit : I am having a feeling that timeSetEvent and the called function is doing something at the same time that makes this thing happen..

> The assert code actually found ct->freed to be 1, even though it was supposed to be freed already

freeing memory doesn't magically destroy all the values stored there, it just means you should no longer access it. Though having said that, some debug versions of free do trash the memory so you know immediately if you're looking at freed memory.

At ANY point in time after the free, the memory may be re-used by something else, which may in turn store the value 1 where you did.

free(ct);ct = NULL;
is the better way to go if you want to make sure that you don't try and access memory after a free.

> Could this be because of multithreading?
No, it's a universal problem.

> Or is this the compiler's error?
No.

> Or am I missing something?
Yes - see above.

As for your first question, which compiler are you using on windows?

Thanks for the help. I actually found out that the error was caused by another error, which causes another error, and causes this error. Basically an object was destroyed from a child procedure, and the parent procedure still used it. Silly me.. that was the most annoying bug I've had for a while, but now it's fixed :D.

So.. freeing doesn't really protect the memory from being accessed. I guess that explained why strange things occured..

I'm currently using gcc mingw32 that I got from the latest beta dev-c++ distribution. Some annoying things with it was, that assert() failure just quits the program, and doesn't actually show anything. I had to make a modified version of assert..

or is that the same with every other compilers?

btw thanks a lot for that explaination.

edit: and I love your avatar! I think I might steal it ;) just kidding

> that assert() failure just quits the program
Try running the code inside the debugger (dev-c++ comes with one)
Then asserts are trapped, and the debugger should take you to the line of code containing the assert.