By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
446,148 Members | 1,282 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 446,148 IT Pros & Developers. It's quick & easy.

How do we find out stepping over somebody else' memory

P: n/a
There are several occations where we write onto someone else' memory
region. Is there any debugging mechanism to find out which part of the
code is causing this problem?

Dec 8 '05 #1
Share this Question
Share on Google+
5 Replies


P: n/a
NewToCPP wrote:
There are several occations where we write onto someone else' memory
region. Is there any debugging mechanism to find out which part of the
code is causing this problem?


i am not sure what you mean by "someone else'" memory.

if you mean writing foreign process memory that should be easy to
detect in any debugger as the operating system protects such access
violations. any debugger should break at the offending statement.

on the other hand, if you thought about writing into your own memory
off bounds, eg. by overflowing an array or writing into freed memory,
you will have to use tools that enable memory bounds checking. with
such a tool any debugger should provide the same method as above by
breaking at offending statements.

examples are efence for linux
(http://perens.com/FreeSoftware/ElectricFence/) or the page heap
verification mechanism in windows (gflags.exe).

-- peter

Dec 8 '05 #2

P: n/a

NewToCPP wrote:
There are several occations where we write onto someone else' memory
region. Is there any debugging mechanism to find out which part of the
code is causing this problem?


You've started three threads today all about tracking down dynamic
memory bugs. In one of those other threads, someone suggested avoiding
all direct management of memory by using classes that do it for you.
std::vector or another container for collections of objects. Smart
pointers (std::auto_ptr where appropriate, or maybe something from
boost) for single objects. std::string instead of arrays of char. RAII
techniques. And, importantly, only dynamically allocating memory (even
when using classes designed for the purpose) when automatic storage
duration isn't sufficient.

This really is the single biggest step you can take towards avoiding
these bugs. It will be an easy step to take from this moment on with
any new code you write, a harder step to take when maintaining existing
code.

I know I haven't answered your particular question here (I'm not sure
what you mean by "someone else's memory" - another process, another
object in your program, or what?). But I wanted to reiterate the point
that, when you must use dynamic memory, use classes designed to take
the risks away.

Gavin Deane

Dec 8 '05 #3

P: n/a
Here I was referring to memory created by another object in the same
program. For example some memory created by different task (or thread)
in the same program.

Dec 8 '05 #4

P: n/a
NewToCPP wrote:
Here I was referring to memory created by another object in the same
program. For example some memory created by different task (or thread)
in the same program.


Then definitely follow my advice from the other thread. Use standard
containers. Pick an appropriate smart pointer and use it. Use
std::string. Create objects rather than pointers to objects whenever
possible.

If you're worried about threading, then the stock answer is that the C++
Standard doesn't address threading.

That said, check the synchronization primitives (mutexes, events,
critical sections, condition variables) that your platform provides, and
use them to protect your data structures in when necessary.

For further details on synchronization primitives, ask in a newsgroup
dedicated to your platform.
Dec 9 '05 #5

P: n/a
Thanks.

Dec 9 '05 #6

This discussion thread is closed

Replies have been disabled for this discussion.