Marc Roessler wrote:
> Hmm..
> 
> Background: some part of my program is overwriting its own memory...
> After running for some time, it crashes in _resmgr_io_func(), probably while trying to access my resmgr_io_funcs_t 
registered functions...
> 
> So now I need to set a "watchpoint" to some portion of memory. A normal watchpoint probably won't suffice (?) because 
this watches variables being modified, not memory. As the memory is corrupted accidentally (e.g. using memcpy or 
whatever...) i need to watch memory directly.

Actually "normal" watchpoint is the same as the other 
("abnormal"?) and it monitors change in a memory location.

Depending on the underlying hardware (and our support) it 
can use hardware or software watchpoint. Software watchpoint 
may (and usually does) cause program run very slow. Hardware 
watchpoints work great.

When you set a watchpoint in gdb using symbol name, gdb 
looks up its symbol tables to figure out actual address and 
sets a watchpoint.

> 
> Is there any way to do this?
> 
> I had two ideas but don't know whether any of these is feasible:
> 
> 1. Cause a physical exception when trying to write to a certain memory region. The idea is similar to guard pages 
commonly used for growing the stack or for detecting buffer overflow attacks (mark page as non-executable). The question
 is whether granularity is fine enough, and whether this works without modifying the memory layout of the program.... 
remember, changing the memory layout will change the location of the crash, thus rendering the previous choice of the 
watched memory location worthless...

Effectively, hardware watchpoint does that. (facility must 
be present in the CPU and we must have support for it; both 
are true in case of intel cpus). Support for hardware 
watchpoint varies across other architectures.

> 
> 2. gdb can step through code, even when it doesn't know it's source code equivalent (because it works on an asm level)
. So gdb can in principle step through the whole program. So what could in theory be done is to make gdb step through 
the program instruction by instruction, each time comparing the specified memory location with the specified value. When
 it changes, the script stops with gdb in step mode. Now the user can see where the access happened. This can take 
_very_ long to execute, as the control runs on the host. But it should be able to find the accesses automatically.

That would be software watchpoint. And this 
instruction-by-instruction execution is what makes your 
program run very slowly in this mode.



To you as the user, type of watchpoint will be transparent. 
Or semi-transparent since software watchpoint has quite 
visible effects on speed of execution.



Relevant setting in gdb is :

(gdb) set can-use-hw-watchpoints 1

You almost always want to set to "1" (which is also default 
setting).  Only if this, for whatever reason, doesn't work 
(like certain architectures and some older gdbs) you should 
set it to 0 to make gdb request software watchpoint.

Note that can-use-hw-watchpoints does not guarantee that you 
will really get a hw watchpoint, but gdb will request it first.




Hope this helps,

Aleksandar

If you think you overriding heap memory (vs stack or static) you can use Qnx Memory Analysis tool which would trigger 
violation of this sort automatically.
Also if you use 6.4.0 or later with latest gcc you can use "Mudflap" instrumentation which can catch different types of 
memory overflow including stack and
static. If you interested please read corresponding documentation of IDE.

Marc Roessler wrote:
> Hmm..
> 
> Background: some part of my program is overwriting its own memory...
> After running for some time, it crashes in _resmgr_io_func(), probably while trying to access my resmgr_io_funcs_t 
registered functions...
> 
> So now I need to set a "watchpoint" to some portion of memory. A normal watchpoint probably won't suffice (?) because 
this watches variables being modified, not memory. As the memory is corrupted accidentally (e.g. using memcpy or 
whatever...) i need to watch memory directly.
> 
> Is there any way to do this?
> 
> I had two ideas but don't know whether any of these is feasible:
> 
> 1. Cause a physical exception when trying to write to a certain memory region. The idea is similar to guard pages 
commonly used for growing the stack or for detecting buffer overflow attacks (mark page as non-executable). The question
 is whether granularity is fine enough, and whether this works without modifying the memory layout of the program.... 
remember, changing the memory layout will change the location of the crash, thus rendering the previous choice of the 
watched memory location worthless...
> 
> 2. gdb can step through code, even when it doesn't know it's source code equivalent (because it works on an asm level)
. So gdb can in principle step through the whole program. So what could in theory be done is to make gdb step through 
the program instruction by instruction, each time comparing the specified memory location with the specified value. When
 it changes, the script stops with gdb in step mode. Now the user can see where the access happened. This can take 
_very_ long to execute, as the control runs on the host. But it should be able to find the accesses automatically.
> 
> What do you think?
> 
> Greetings,
>  Marc
> 
> _______________________________________________
> General
> http://community.qnx.com/sf/go/post32094
>