memory access violations 
Author Message
 memory access violations

When you build a project in debug mode, it uses the debug memory allocator to
manage the heap. This means that all memory allocations have guard bytes placed
around them. These guard bytes are used to detect errant  memory overwrites.
Various diagnostic routines can be turned on to report any problems. (eg with
afxMemDF |= checkAlwaysMemDF and _heapchk() )

1) I think that local (stack) and global variables also have guard bytes.  
However I cannot see any mechanism for detecting when an overwrite occurs.  Does
anybody know how to do it?

2) We are getting a memory access violation in release mode but never in debug
mode.  I have tried disabling optimisation in the release mode but this does not
stop the problem.  I have enabled all the heap diagnostics while in debug mode
(they cannot operate in release mode) and these have not thrown anything up.  I
would guess that the piece of code that overwrites memory could be far away  from
the code whose memory gets corrupted, so it sounds really tricky to track down.
How would you solve this problem?

thanks



Fri, 21 Nov 2003 22:45:29 GMT  
 memory access violations

Quote:
>How would you solve this problem?

I'd probably check the debug build using a product such as
BoundsChecker or Purify to see if they identify something. If that
doesn't help, I'd try them on the release build, and eventually I'd
debug the release build to try and see what's going on.

Have a look at "Common Problems Switching from Debug to Release Build"
in your VC++ help.

To debug your release version see "Turn on Generation of Debug
Information for the Release Build" in your VC++ help.

Dave
--
MVP VC++ FAQ: http://www.mvps.org/vcfaq
My address is altered to discourage junk mail.
Please post responses to the newsgroup thread,
there's no need for follow-up email copies.



Sat, 22 Nov 2003 00:30:46 GMT  
 memory access violations
Make sure you're compiling with /GZ in debug mode.

Try using BoundsChecker (expensive) or pageheap1 (free).

Quote:

> When you build a project in debug mode, it uses the debug memory allocator to
> manage the heap. This means that all memory allocations have guard bytes placed
> around them. These guard bytes are used to detect errant  memory overwrites.
> Various diagnostic routines can be turned on to report any problems. (eg with
> afxMemDF |= checkAlwaysMemDF and _heapchk() )

> 1) I think that local (stack) and global variables also have guard bytes.
> However I cannot see any mechanism for detecting when an overwrite occurs.  Does
> anybody know how to do it?

> 2) We are getting a memory access violation in release mode but never in debug
> mode.  I have tried disabling optimisation in the release mode but this does not
> stop the problem.  I have enabled all the heap diagnostics while in debug mode
> (they cannot operate in release mode) and these have not thrown anything up.  I
> would guess that the piece of code that overwrites memory could be far away  from
> the code whose memory gets corrupted, so it sounds really tricky to track down.
> How would you solve this problem?

> thanks

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


Sat, 22 Nov 2003 00:32:41 GMT  
 memory access violations
: 1) I think that local (stack) and global variables also
: have guard bytes.  However I cannot see any
: mechanism for detecting when an overwrite occurs.
: Does anybody know how to do it?

Stack pages are guarded for overflow and underflow.  Reference Richter,
Programming Applications for  Windows, pp. 559-569.  ISBN 1-57231-996-8.
Basically, the pages are marked PAGE_GUARD, which allows application to
catch the exceptions generated on a write.

I don't know about heap guards (outside of synchronization, or queuing
of requests into the heap).

: 2) We are getting a memory access violation in
: release mode but never in debug mode.

Build the release with a map file and debug symbols.  The map file will
be useful if a customer sends you a dump (you can't duplicate on
premises).  Debug will be useful if you can duplicate and attach a
de{*filter*}.

A few of the fellows who answer questions have links on their sites
about release builds with debug info, and the infamous access violation
in release mode.

I also prefer to use BoundsChecker.

Jeff


When you build a project in debug mode, it uses the debug memory
allocator to
manage the heap. This means that all memory allocations have guard bytes
placed
around them. These guard bytes are used to detect errant  memory
overwrites.
Various diagnostic routines can be turned on to report any problems. (eg
with
afxMemDF |= checkAlwaysMemDF and _heapchk() )

1) I think that local (stack) and global variables also have guard
bytes.
However I cannot see any mechanism for detecting when an overwrite
occurs.  Does
anybody know how to do it?

2) We are getting a memory access violation in release mode but never in
debug
mode.  I have tried disabling optimisation in the release mode but this
does not
stop the problem.  I have enabled all the heap diagnostics while in
debug mode
(they cannot operate in release mode) and these have not thrown anything
up.  I
would guess that the piece of code that overwrites memory could be far
away  from
the code whose memory gets corrupted, so it sounds really tricky to
track down.
How would you solve this problem?

thanks



Sat, 22 Nov 2003 07:37:56 GMT  
 
 [ 4 post ] 

 Relevant Pages 

1. memory access violation

2. Memory Access Violation in Release mode only

3. Memory Access Violation in Release Mode-Solution Found

4. Memory Access Violation in Release Mode-Solution Found

5. Memory Access Violation in Release Mode

6. BUG: Memory Access Violation Uses Repeated Realloc's For Small Bl ocks Q225099

7. NT 4.0 allows memory access violations!!!

8. Memory access violation using CRecordset and date/time fields

9. NT 4.0 unchecked memory access violation!!!

10. map::insert - Memory Access Violation Error

11. <string>,memory access violation

12. Memory Access Violation in Release Mode-Solution Found

 

 
Powered by phpBB® Forum Software