Why not make your linked list a class and put all the deallocation calls in the destructor of the linked list class?

I'm thinking about it. It's actually someone elses c code I am using (which I have have made c++ compilable).

A list class sounds good, but the problem is making the list class good enough to handle having double arrays in lists in lists (as actually occurs).

And a double array class...

Edited by - ludemann8 on April 3, 2001 11:31:17 AM

Uhm, what do you mean by double array? Do you mean multi-dimensional array?

yep. It''s one of the structures used throughout... a 2 dimensional array of doubles (though by double before I meant 2)

ludemann8:

1. AFAIK, getting at the call stack outside of the debugger would be a horrible job - you''d probably have to use functions from the ImageHlp library such as StackWalk() - thats akin to using a sledge hammer to crack a nut.



2. An alternative (easier) way is to cause a breakpoint in MSVC when a leaking allocation takes place. This is a two phase operation, first you make a list of the leaks, second you get the debugger to cause a breakpoint at the place where the allocation which caused that leak occurred - from there you can use the usual debugger callstack to work backwards:

a. Remove any clean up or custom allocation code you''ve added - you want the memory leaks to occur and for MSVC to use the C runtime library debug heap.

b. #include in the file with WinMain in.

c. At the start of the program (WinMain) or subsection of program, insert the following:
_CrtSetDbgFlag( _CrtSetDbgFlag(0)|_CRTDBG_LEAK_CHECK_DF );
[there are other flags which do other useful things]

d. Run the program and quit normally.

e. When you quit, all memory leaks will be listed:
Detected memory leaks!
Dumping objects ->
{27} normal block at 0x00CFA1EC, 65536 bytes long.
...blah...

f. For each leak, write down the number in the curly braces, in this case {27}. The number is the allocation number (the debug heap keeps a count of how many allocations have taken place per process, in this case, the 27th allocation, which I didn''t free.

g. Press F11 to start a debug session for the program, the debugger should stop at the start of WinMain (or other entry point).

h. In the watch window on the right of the debugger (next to the variables and context), enter the following variable name:
_crtBreakAlloc

i. Its value will be set to -1, change it to the allocation number you want to find (say 27).

j. Now press F5 to resume debugging, when the program allocates the 27th allocation (the one which isn''t free''d) it will cause a breakpoint and control will return to the debugger.

k. You will be in a function called _heap_alloc_dbg which is four steps away from the allocation - simply look at the call stack and you''ll see the culprit allocation.

l. Repeat steps f-k until program has no more leaks.



3. An alternative, automated way to do the above is to use BoundsChecker from nuMega (www.numega.com) - IIRC they have a 30 day trial version which may be enough to find all your bugs.



4. You''ve learnt an important lesson - check your code for leaks and errors while you''re writing it - they''re miles easier to find when you know that it only started leaking after you added function x.

--
Simon O''''Connor
Creative Asylum Ltd
www.creative-asylum.com

There is no doubt about it... you rule the world.
Thank you so much....

That was me ;-)

Edited by - ludemann8 on April 3, 2001 1:59:57 PM

BTW: in the #include above should be crtdbg.h in < and > brackets - seems the board chomped them up.