Looking for information on execute vs go 
Author Message
 Looking for information on execute vs go

I am developing a multithreaded MFC Visual C++ application under Visual
Studio. I am building the Win32-Release configuration. The application
runs correctly if I start the application using the de{*filter*} (F5) or
attach the de{*filter*} to the process once the application is started.  The
application I start the application using execute (Ctrl-F5).  Any
suggestions on where to find information on how debugging would affect
the execuition of the process being debugged?

Howard Weiss



Sun, 08 Jul 2001 03:00:00 GMT  
 Looking for information on execute vs go
The main difference is the memory layout of your application.  When your
application is being debugged the de{*filter*} becomes a _PART_ of the debugee
(the process your debugging).  So the memory layout of your app drastically
changes (especially since VC++ uses lots of memory).  SO the most likly
cause of the problem is some kind of memory overwrite.  When the de{*filter*} is
attached you have a much bigger memory pool, so your overwriting stuff which
isn't "critical".  But when your not debugging then your app is very tight
in memory and overwrites will cause all kinds of havoc.

Memory writes occur if you use a pointer without allocating memory for it,
overwrite the ends of an array, ect...  The VC++ debug library comes with
some helpful routines (see CrtSetDbgFlag and associated functions).  Lastly
i would suggest "Bounds Checker" by numega, I believe they have a free trial
version on their web site

--
Visit: http://www.*-*-*.com/



Sun, 08 Jul 2001 03:00:00 GMT  
 Looking for information on execute vs go
That is incorrect. When debugging the de{*filter*} is in a separate process.
The de{*filter*} has to use ReadProcessMemory() and WriteProcessMemory()
to read and write the debuggee's memory. The debugee cannot accidentally
read or write the de{*filter*}'s memory (thank goodness) and it's memory
map is not affected by being debugged. If you generate a memory map of
the de{*filter*} and the debuggee you can see this.

What is different?

Exception handling is different, since the de{*filter*} is given a chance to handle
exceptions. Timing can be different, since the de{*filter*} is using CPU time and
is being sent debug notifications about certain events.
Switching to and from the de{*filter*} and debuggee can cause different window
messages to be sent. Finally, applications can explicitly test for the de{*filter*}
and behave differently (at least under Win9x and WinNT).

Of course, with the broken Win9x architecture the de{*filter*} and debuggee
(and all other processes) are sharing the 2GByte to 3GByte range, but that
usually doesn't cause a problem.

Using BoundsChecker, the VC++ debug memory allocators, or some other
overwrite bug finder is always a good idea.

Quote:

> The main difference is the memory layout of your application.  When your
> application is being debugged the de{*filter*} becomes a _PART_ of the debugee
> (the process your debugging).  So the memory layout of your app drastically
> changes (especially since VC++ uses lots of memory).  SO the most likly
> cause of the problem is some kind of memory overwrite.  When the de{*filter*} is
> attached you have a much bigger memory pool, so your overwriting stuff which
> isn't "critical".  But when your not debugging then your app is very tight
> in memory and overwrites will cause all kinds of havoc.

> Memory writes occur if you use a pointer without allocating memory for it,
> overwrite the ends of an array, ect...  The VC++ debug library comes with
> some helpful routines (see CrtSetDbgFlag and associated functions).  Lastly
> i would suggest "Bounds Checker" by numega, I believe they have a free trial
> version on their web site

> --
> Visit: http://www.*-*-*.com/

--
.Bruce Dawson, Cavedog Entertainment.
Makers of Total Annihilation - http://www.*-*-*.com/


Fri, 13 Jul 2001 03:00:00 GMT  
 Looking for information on execute vs go
Also : Context Switches (which thread is active)  may be vastly different
under the de{*filter*}.  (This really falls under Bruce's category of 'timing',
but it doesn't exist in single-threaded apps.)

DanL

Quote:

>I am developing a multithreaded MFC Visual C++ application under Visual
>Studio. I am building the Win32-Release configuration. The application

>What is different?

>Exception handling is different, since the de{*filter*} is given a chance to
handle
>exceptions. Timing can be different, since the de{*filter*} is using CPU time
and
>is being sent debug notifications about certain events.
>Switching to and from the de{*filter*} and debuggee can cause different window
>messages to be sent. Finally, applications can explicitly test for the
de{*filter*}
>and behave differently (at least under Win9x and WinNT).



Mon, 16 Jul 2001 03:00:00 GMT  
 
 [ 4 post ] 

 Relevant Pages 

1. Looking for Information / Sample of Addin for VS.NET

2. f5 vs cntl+f5 (debug vs execute)

3. Difference between Go and Execute Program

4. Execute command has gone from Connection ?

5. Company going public next year is looking for C++ Programmers

6. Newbie: Looking for Simplest Code to OpenConnection, OpenRecordset, Execute A SQL Statement Insert/Update

7. Looking for a way to find CPU time to execute

8. Looking for information, Help appreciated

9. F5 vs. pressing the Go button/Menu

10. ADO ?: Open vs. Execute

11. ADO Question: open vs. execute

12. Execute vs. Run program

 

 
Powered by phpBB® Forum Software