Re: class destructor bomb? An answer, & a debug question

[algruber]

Ralph, What exactly is the name of the file I'm missing. I do have several
"CRT" files, e.g, msvcrtd.lib, crtdbg.h, etc. in VC98\lib and \include.
Thanx

The Answer: it has been explained to me that you can't have a destructor
and pass a class multiple times to a recursive routine because it will try
to delete the same passed in class for each recursion. What do you think?

"ralph" <nt_consulting32@SPAMhotmail.com> wrote:
>
>Comments placed inside post.
>
>"algruber" <algruber@home.com> wrote:
>>
>>Here's a peculiar problem where a possibly bad destructor is causing me
>to
>>bomb where I wouldn't expect to. Can you help?
>>
>>Main points:
>>1. I declare & define a Linked list class in "ListType.h"
>>2. My main() creates a list and calls RevPrint() to print 5 integers in
>reverse
>>order.
>>3. The program compiles fine with MS VC++ 6.0.
>>4. It bombs at RevPrint() with:
>> msgbox 1: "Debug Assertion Failed!"
>> File: dbgdel.cpp
>> "Expression: _BLOCK_TYPE_IS_VALID(pHead->nBlockUse)
>> msgbox 2: "program has performed an illegal operation & will be shut down"
>>5. If I choose "debug" it asks me for dbgdel.cpp and new.cpp, neither of
>>which are in my 2-file program. Then it says "User breakpoint called from
>>code at hex-whatsis", even though I haven't set any breakpoints.
>> ...
>
> -----------------------------------------------
>First lets repair your 'debug' environment...
>You need to have installed the crt/src (c runtime source files) and then
>make sure the directory is included under 'source files' in the option::directories
>configuration.
>If you don't do this, you will not receive the maximum support from your
>debug environment.
>
>What is happening is your code has hit an ASSERT() call in the debug code,
>which then activates the debugger, instead of an exception or system error.
>(That is the 'User' call) If you had the crt code loaded the debugger will
>show you the exact location and item your code failed on.
>
>IMHO: Also put some whitespace in your code. I know K&R looks like something
>the big boys do, and running things together makes it all sooo cool. But
>it is a 'bad' habit like smoking, you're ok with it, but it annoys everyone
>around you. It also causes errors.
>
>Your code is a bit difficult to read but it looks like you went one delete
>too far.
>
>Whenever moving things around seems to cure the problem, you can be sure
>you are walking off the end of something.
>
>Hope this helps.
>

[ralph]

"algruber" <algruber@home.com> wrote:
>
>Ralph, What exactly is the name of the file I'm missing. I do have several
>"CRT" files, e.g, msvcrtd.lib, crtdbg.h, etc. in VC98\lib and \include.
>Thanx
>
>The Answer: it has been explained to me that you can't have a destructor
>and pass a class multiple times to a recursive routine because it will try
>to delete the same passed in class for each recursion. What do you think?
>
>"ralph" <nt_consulting32@SPAMhotmail.com> wrote:
>>
>>Comments placed inside post.
>>
>>"algruber" <algruber@home.com> wrote:
>>>
>>>Here's a peculiar problem where a possibly bad destructor is causing me
>>to
>>>bomb where I wouldn't expect to. Can you help?
>>>
>>>Main points:
>>>1. I declare & define a Linked list class in "ListType.h"
>>>2. My main() creates a list and calls RevPrint() to print 5 integers in
>>reverse
>>>order.
>>>3. The program compiles fine with MS VC++ 6.0.
>>>4. It bombs at RevPrint() with:
>>> msgbox 1: "Debug Assertion Failed!"
>>> File: dbgdel.cpp
>>> "Expression: _BLOCK_TYPE_IS_VALID(pHead->nBlockUse)
>>> msgbox 2: "program has performed an illegal operation & will be shut
down"
>>>5. If I choose "debug" it asks me for dbgdel.cpp and new.cpp, neither
of
>>>which are in my 2-file program. Then it says "User breakpoint called
from
>>>code at hex-whatsis", even though I haven't set any breakpoints.
>>> ...
>>
>> -----------------------------------------------
>>First lets repair your 'debug' environment...
>>You need to have installed the crt/src (c runtime source files) and then
>>make sure the directory is included under 'source files' in the option::directories
>>configuration.
>>If you don't do this, you will not receive the maximum support from your
>>debug environment.
>>
>>What is happening is your code has hit an ASSERT() call in the debug code,
>>which then activates the debugger, instead of an exception or system error.
>>(That is the 'User' call) If you had the crt code loaded the debugger will
>>show you the exact location and item your code failed on.
>>
>>IMHO: Also put some whitespace in your code. I know K&R looks like something
>>the big boys do, and running things together makes it all sooo cool. But
>>it is a 'bad' habit like smoking, you're ok with it, but it annoys everyone
>>around you. It also causes errors.
>>
>>Your code is a bit difficult to read but it looks like you went one delete
>>too far.
>>
>>Whenever moving things around seems to cure the problem, you can be sure
>>you are walking off the end of something.
>>
>>Hope this helps.
>>
>

As for the answer it sounds weak. I apologize for not taking the time to
run the program. I am travelling lite and don't have a full development environment
at the moment. (Loose translation: I can't test anything just shoot my mouth
off. <g>)

I perceived the situation as two problems - one, the debug environment needed
to be set up correctly and two, the actual logic fault. The advice I gave
was how to get your environment setup. To do that...

If you used the standard setup for VC++ you should have a folder like this:
c:\Prog~Files\M$ Visual Studio\vc98\crt\src\
In this folder is the source code for the crt runtime files (about 500+).
access.c, conio.c, dbgheap.c, dbgdel.cpp, new.cpp, etc.

If you don't have them you can load them from the cd by either extracting
the .cab, or just run setup, custom, and select them.

It is also possible that you do have the files but the folder has not been
included in your configuration: Tools::Options::Directories Tab.

If you had that setup up the following scenario would have been different:
>
>>>5. If I choose "debug" it asks me for dbgdel.cpp and new.cpp, neither
of
>>>which are in my 2-file program. Then it says "User breakpoint called
from
>>>code at hex-whatsis", even though I haven't set any breakpoints.
>>> ...

The debug would have stopped at the assert statement in the crt code which
called the "User breakpoint" (int3). This I believe, you would agree, would
go along way in helping to resolve your problem.

As for the actual problem, I assumed by just looking thru the code and seeing
multiple deletes in a loop it was most likely you were "over-running" one
of the loops. Unfortunately that is only a best ('wild' might be a better
word) guess.

The answer you were given sounds a little weak because if that were the case,
memory shouldn't have been corrupted anyway. If you were destroying the class
each time thru, it would be gone and that would be that. Destructors get
called when they go out of scope or with a delete (again by something higher
in scope). So obviously passing a 'copy' of something to a recursive routine
would buy you nothing but a one time trip or a stack over run. Passing a
reference would have no effect and is OK. (assuming you aren't trying to
delete the thing inside the recursive routine).

I note you are not passing a reference which is not a good idea.

With a recursive you are running the same code instructions, but you are
getting a new set of auto variables everytime you enter anew - the stack
just keeps growing. I suspect you are trying to delete an uninitialized list
element (list is not the same animal you started with).

Add the debug crt src, and step thru it a couple of times - I believe you
will nail it in a few minutes.

[Danny Kalev]

algruber wrote:
>
> Ralph, What exactly is the name of the file I'm missing. I do have several
> "CRT" files, e.g, msvcrtd.lib, crtdbg.h, etc. in VC98\lib and \include.
> Thanx
>
> The Answer: it has been explained to me that you can't have a destructor
> and pass a class multiple times to a recursive routine because it will try
> to delete the same passed in class for each recursion. What do you think?

I didn't look at your source files but this explanation is simply
incorrect. A class that needs a destructor should have one, period. If
its ctor allocates memory or some other resources, these must be freed
in the dtor or else your code becomes a time bomb. The crash you
experiences can be most likely attributed to a bug. My guess is that you
try to write past a buffer, write to uninitialized memory or delete the
same object twice. It's always one of these, trust me.

Danny