On Aug 17, 1:35 pm, Kenneth Porter <shiva.blackl...@sewingwitch.com>
wrote:
Put the reference in a page by itself:
struct foo
{
char sentinel1[2048];
X& x;
char sentinel2[2048];
};
This will also catch an overwrite that's touching neighboring addresses.
Set the sentinels to a known pattern and periodically make sure the
pattern
is unscathed.
What CPU are you using? Does it support a per-word data watch? You might
be
able to use the CPU's debugging features to trap accesses to that
address.
I was thinking of that, but I don't think it would work. Because the
structure is changed and reference itself most likely won't be changed
anymore.
I'm using HTC mobiles phones with samsung 2442 400mhr ARMV4I cpu
On Aug 17, 1:40 pm, "Victor Bazarov" <v.Abaza...@comAcast.net> wrote:
It sounds like a memory corruption defect in your program (unless it
is in the system on which you're running, which I doubt). The usual
way to find out when it happens is to put a special breakpoint in
your debugger, which should allow to watch for changes in the data
at an arbitrary location in memory. If it doesn't, you're in for
a long session of trying to find who is changing that memory by
stepping through your program and watching the value of the reference.
Put a breakpoint somewhere halfway between the start of the program
and the point at which you know it happens. When your debugger hits
that new breakpoint, see if it has happened. If it didn't, put the
second breakpoint in the middle (approx) of the second part of your
range. Continue. If it has actually happen, put another breakpoint
in the middle of the first half. Restart. This is how most of us
who use subpar debuggers find where sh!t happens in our programs.
Another way is to figure out the true address of the reference member
and put a whole lot of debug printouts in an attempt to narrow it
down, but that means changing your code which can suddenly stop
exhibiting the wrong behaviour.
All this was an option, but I can't use it. Defect is in the code for
sure. Code sucks BIG time, it's a monster framework from a big
telephony company, written by MANY employees around the globe. So,
original developers cannot be contacted... nobody knows what's up etc.
So, I'm working on it now.
Why I can't use VS debugger. It was an option, but the problem is that
this reference is part of a small class that's often created/deleted
in MANY places. It's a Timer (which actually works as a timeout - runs
a function after xxx milliseconds) object and it has a reference to
TimerManager object. For now I removed some crap from there just to
fix the problem, but still source of problem is unknown and unlikely
to be caught any soon :)
Debug printouts really work... and it always crashes in exactly the
same place. Printouts show that value gets magically changed just
before the crash... but who changed it I have no idea. More over after
it becomes corrupted vs debugger shows some strange stuff in debugger.
The TimerManager is a virtual class, and when it's corrupted vs shows
v_ptr as 0. Is vptr a part of object itself? Seems to be so to resolve
the final object.
instance. One thing you *might* be able to do is attempt to look at what is
class/instance it is by it's pattern. Just get the address of the referenc
and output the bytes located there so you can see them. Try to determine
what class is it, then you'll have somewhere to look at least. It could be
a class, it could be data, coudl be anythign overflowing memory.