NULL Class Pointers in Debug Watch Windows 
Author Message
 NULL Class Pointers in Debug Watch Windows

I have a bug I'm trying to track down that is a memory leak in a "vanilla"
(un-managed) C++ class. In general, I set a potential array pointer to NULL
if I want to indicate if it has never been allocated. That's because "delete
[] "can't deal with something that hasn't been allocated, so I check to see
if it's set to NULL before I attempt to delete.

Problem is, in the de{*filter*} if  I set a pointer to a class to NULL it looks
like there is a class instance there. This does not happen with, say, a long
array (it says 'null'). The de{*filter*} doesn't recognize NULL (or even 'null',
even though it uses it). NULL is #defined as '0' (zero), but an attempt to
see if the class instance address pointer is set to 0 if it's NULL returns
false. So how do do see if a class pointer is NULL in the de{*filter*}? Is there
a better choice than NULL?

The bug is even weirder. I have a class that intializes one of it's members,
a long array pointer, to NULL. The program will either leave this alone or
allocate space for member via 'new long[size]'. So, it should either still
be NULL or allocated. Yet, occasionally when the destructor is evoked it
causes an error (which is an exception, with no explanation, but since it's
during a delete, must be a memory leak problem) in the line where I delete
the array, but check for it equalling NULL first, ala:

class MyClass
{
   public:

   MyClass( )
   {
      this->MyLongArray = NULL ;
   } ;

   ~MyClass( )
   {
      // exception error happens in line below //

      if  ( this->MyLongArray != NULL ) { delete [] this->MyLongArray ;
this->MyLongArray = NULL ; }
   } ;

   public:

   long MyLongArray* ;  // yeah, its public, so sue me :)

Quote:
} ;

The exception message says:

"Unhandled exception at 0x77f7f570 in MyApplication.exe: User breakpoint.".

Any ideas? Thanx in advance...

  /== Peteroid ==\



Tue, 22 Feb 2005 15:30:18 GMT  
 NULL Class Pointers in Debug Watch Windows
Figured out the bug (writing past allocated memory), but my question about
the de{*filter*} not recognizing NULL is a subject I'd still like some incite
into... :)

 /== Peteroid ==\


Quote:
> I have a bug I'm trying to track down that is a memory leak in a "vanilla"
> (un-managed) C++ class. In general, I set a potential array pointer to
NULL
> if I want to indicate if it has never been allocated. That's because
"delete
> [] "can't deal with something that hasn't been allocated, so I check to
see
> if it's set to NULL before I attempt to delete.

> Problem is, in the de{*filter*} if  I set a pointer to a class to NULL it
looks
> like there is a class instance there. This does not happen with, say, a
long
> array (it says 'null'). The de{*filter*} doesn't recognize NULL (or even
'null',
> even though it uses it). NULL is #defined as '0' (zero), but an attempt to
> see if the class instance address pointer is set to 0 if it's NULL returns
> false. So how do do see if a class pointer is NULL in the de{*filter*}? Is
there
> a better choice than NULL?

> The bug is even weirder. I have a class that intializes one of it's
members,
> a long array pointer, to NULL. The program will either leave this alone or
> allocate space for member via 'new long[size]'. So, it should either still
> be NULL or allocated. Yet, occasionally when the destructor is evoked it
> causes an error (which is an exception, with no explanation, but since
it's
> during a delete, must be a memory leak problem) in the line where I delete
> the array, but check for it equalling NULL first, ala:

> class MyClass
> {
>    public:

>    MyClass( )
>    {
>       this->MyLongArray = NULL ;
>    } ;

>    ~MyClass( )
>    {
>       // exception error happens in line below //

>       if  ( this->MyLongArray != NULL ) { delete [] this->MyLongArray ;
> this->MyLongArray = NULL ; }
>    } ;

>    public:

>    long MyLongArray* ;  // yeah, its public, so sue me :)
> } ;

> The exception message says:

> "Unhandled exception at 0x77f7f570 in MyApplication.exe: User
breakpoint.".

> Any ideas? Thanx in advance...

>   /== Peteroid ==\



Wed, 23 Feb 2005 00:29:37 GMT  
 NULL Class Pointers in Debug Watch Windows
NULL is a macro. The de{*filter*} has no knowledge of macros. Literal zero
should indeed work fine in all cases.

Ronald Laeremans
Visual C++ compiler and libraries team


Quote:
> Figured out the bug (writing past allocated memory), but my question about
> the de{*filter*} not recognizing NULL is a subject I'd still like some incite
> into... :)

>  /== Peteroid ==\



> > I have a bug I'm trying to track down that is a memory leak in a
"vanilla"
> > (un-managed) C++ class. In general, I set a potential array pointer to
> NULL
> > if I want to indicate if it has never been allocated. That's because
> "delete
> > [] "can't deal with something that hasn't been allocated, so I check to
> see
> > if it's set to NULL before I attempt to delete.

> > Problem is, in the de{*filter*} if  I set a pointer to a class to NULL it
> looks
> > like there is a class instance there. This does not happen with, say, a
> long
> > array (it says 'null'). The de{*filter*} doesn't recognize NULL (or even
> 'null',
> > even though it uses it). NULL is #defined as '0' (zero), but an attempt
to
> > see if the class instance address pointer is set to 0 if it's NULL
returns
> > false. So how do do see if a class pointer is NULL in the de{*filter*}? Is
> there
> > a better choice than NULL?

> > The bug is even weirder. I have a class that intializes one of it's
> members,
> > a long array pointer, to NULL. The program will either leave this alone
or
> > allocate space for member via 'new long[size]'. So, it should either
still
> > be NULL or allocated. Yet, occasionally when the destructor is evoked it
> > causes an error (which is an exception, with no explanation, but since
> it's
> > during a delete, must be a memory leak problem) in the line where I
delete
> > the array, but check for it equalling NULL first, ala:

> > class MyClass
> > {
> >    public:

> >    MyClass( )
> >    {
> >       this->MyLongArray = NULL ;
> >    } ;

> >    ~MyClass( )
> >    {
> >       // exception error happens in line below //

> >       if  ( this->MyLongArray != NULL ) { delete [] this->MyLongArray ;
> > this->MyLongArray = NULL ; }
> >    } ;

> >    public:

> >    long MyLongArray* ;  // yeah, its public, so sue me :)
> > } ;

> > The exception message says:

> > "Unhandled exception at 0x77f7f570 in MyApplication.exe: User
> breakpoint.".

> > Any ideas? Thanx in advance...

> >   /== Peteroid ==\



Wed, 23 Feb 2005 01:55:48 GMT  
 
 [ 3 post ] 

 Relevant Pages 

1. VS Watch and other debug windows inaccessible

2. TC++ 3.0 Debug, Watching pointer variables

3. DEBUG od TC++ 3.0, Watches on pointer var.

4. Memory watch windows or debug trap?

5. Dispaly/Dump class contents in debug/watch window

6. How to use the Watch Window to debug class (last message had wrong email)

7. How to use the Watch Window to debug classes

8. confused null pointer with null pointer constant

9. MS C 5.0 NULL Pointer Debugging

10. NULL v null pointer constant

11. Global pointer is null sometimes even when initialized to some non-null value

12. NULL as a null function pointer

 

 
Powered by phpBB® Forum Software