Apparent corruption caused by the debugger / ASSERT 
Author Message
 Apparent corruption caused by the debugger / ASSERT

Can anybody explain this one?

    classPointer* newPtr = currentPtr;
    ASSERT( currentPtr != NULL );
    ASSERT( FALSE );

The program crashed at the second ASSERT, of course. But, when examining the data
values via the de{*filter*}, the really puzzling thing is that the value of "newPtr"
is not NULL but the value of "currentPtr" is!?

I've had to resort to this method of debugging my program as the machine I'm
working on is VERY slow and to run it to this point via F5 is impossible.

To further complicate the matter, if I remove the debug code, the apparent
corruption of "currentPtr" doesn't occur.

Regards,

Kev Gilbert



Mon, 06 Oct 2003 09:38:12 GMT  
 Apparent corruption caused by the debugger / ASSERT

Quote:

> Can anybody explain this one?

>     classPointer* newPtr = currentPtr;
>     ASSERT( currentPtr != NULL );
>     ASSERT( FALSE );

> The program crashed at the second ASSERT, of course. But, when examining the data
> values via the de{*filter*}, the really puzzling thing is that the value of "newPtr"
> is not NULL but the value of "currentPtr" is!?

> I've had to resort to this method of debugging my program as the machine I'm
> working on is VERY slow and to run it to this point via F5 is impossible.

> To further complicate the matter, if I remove the debug code, the apparent
> corruption of "currentPtr" doesn't occur.

> Regards,

> Kev Gilbert

You might try using DebugBreak() instead of ASSERT(FALSE).  There are
cases in MFC where the ASSERT pops up a message box but it lets the
program continue executing in some fashion.  A really horrible idea!

--
Scott McPhillips [VC++ MVP]



Mon, 06 Oct 2003 11:21:46 GMT  
 Apparent corruption caused by the debugger / ASSERT

Quote:
-----Original Message-----

> Can anybody explain this one?

>     classPointer* newPtr = currentPtr;
>     ASSERT( currentPtr != NULL );
>     ASSERT( FALSE );

> The program crashed at the second ASSERT, of course. But, when examining the
data
> values via the de{*filter*}, the really puzzling thing is that the value of "newPtr"
> is not NULL but the value of "currentPtr" is!?

> I've had to resort to this method of debugging my program as the machine I'm
> working on is VERY slow and to run it to this point via F5 is impossible.

> To further complicate the matter, if I remove the debug code, the apparent
> corruption of "currentPtr" doesn't occur.

> Regards,

> Kev Gilbert

You might try using DebugBreak() instead of ASSERT(FALSE).  There are
cases in MFC where the ASSERT pops up a message box but it lets the
program continue executing in some fashion.  A really horrible idea!

--
Scott McPhillips [VC++ MVP]
.
Scott,

You are correct re the program continuing.

I've got a timer firing that uses the "currentPtr" variable. I placed a "divide
by zero" bomb in the timer routine that would only fire when the ASSERT( FALSE )
was about to be executed. I got thwe "Assert" dialog box FOLLOWED by the "Divide
by zero" dialog box.

Yuk!



Mon, 06 Oct 2003 12:01:52 GMT  
 Apparent corruption caused by the debugger / ASSERT
It can be extremely important to understand why and how programs appear
to 'continue executing' when an assert dialog comes up.

The ASSERT() macro calls a function to bring up the dialog box, and that
function does not return until you dismiss the dialog box. This can be verified
in a number of ways. However, what does happens is that the dialog box,
like all dialog boxes, runs a message pump. This message pumps will
dispatch messages for all of the windows in your thread. Therefore, the
message box may end up implicitly calling back to your code.

The worst case is if you put an assert in a WM_TIMER or WM_PAINT
message. Usually you will get infinite recursion and crash before the assert
dialog comes up.

The simple 'solution' is to have a custom assert function that watches for
recursion and does a DebugBreak() when it detects it.

A fancier method is to have a custom assert function that starts a new
thread and opens the message box from there - since message queues
are thread specific, this avoids the problem.

Unfortunately, starting a thread at 'unexpected' times can cause different
problems, so the *real* solution is to start an assert thread when your
program starts and then signal that thread when you want to display
an assert dialog. The thread that asserts then waits for a response, and
does the right thing.

It's a hassle, and I wish MS would fix it (as well as adding an "Ignore
Always" button, and renaming the silly "Retry" button) but I see no
sign that they will.

In short: the problem is due to the behaviour or Windows dialogs.

Quote:

> -----Original Message-----

> > Can anybody explain this one?

> >     classPointer* newPtr = currentPtr;
> >     ASSERT( currentPtr != NULL );
> >     ASSERT( FALSE );

> > The program crashed at the second ASSERT, of course. But, when examining the
> data
> > values via the de{*filter*}, the really puzzling thing is that the value of "newPtr"
> > is not NULL but the value of "currentPtr" is!?

> > I've had to resort to this method of debugging my program as the machine I'm
> > working on is VERY slow and to run it to this point via F5 is impossible.

> > To further complicate the matter, if I remove the debug code, the apparent
> > corruption of "currentPtr" doesn't occur.

> > Regards,

> > Kev Gilbert

> You might try using DebugBreak() instead of ASSERT(FALSE).  There are
> cases in MFC where the ASSERT pops up a message box but it lets the
> program continue executing in some fashion.  A really horrible idea!

> --
> Scott McPhillips [VC++ MVP]
> .
> Scott,

> You are correct re the program continuing.

> I've got a timer firing that uses the "currentPtr" variable. I placed a "divide
> by zero" bomb in the timer routine that would only fire when the ASSERT( FALSE )
> was about to be executed. I got thwe "Assert" dialog box FOLLOWED by the "Divide
> by zero" dialog box.

> Yuk!

--
.Bruce Dawson, Humongous Entertainment (we're hiring).
http://www.*-*-*.com/
Send job applications by e-mail, post technical questions
to the newsgroups please. Thanks.


Tue, 04 Nov 2003 05:24:55 GMT  
 
 [ 4 post ] 

 Relevant Pages 

1. longjmp, apparent corruption in some rare circumstances?

2. Will this code cause memory corruption?

3. overflow causing surrounding memory corruption

4. ReadFile causes memory corruption in Input Parameters

5. ReadFile causes memory corruption in Input Parameters

6. LPCTSTR : Causing corruption?

7. CException-derived class causes heap corruption

8. CStringT::LoadString() causes assert; KB150764 not helpful

9. assert() causes compile problem in Visual C++

10. Unload composite control causes Assert in Atlwin.h, Line 2281

11. database exception causes debug assert in CdbDBEngine

12. HELP!!! CRecordset::Close is causing an assert

 

 
Powered by phpBB® Forum Software