|
And here's
where it gets tricky, because I don't think the damage is being done by this
particular thread. He already told us when he looks at the stack frame
of the calling function all the variables look right, they would have to be
overwritten first if this was a stack overwrite by this thread. So my
guess is somewhere else he's sharing a certain set of pointers between threads
and one of these other threads is stepping on the stack here.
Yeah, there's nothing in Jason's code that make it
possible for the thread to get corrupted by itself. Definitely something
is writing junk to it from outside (which means other
threads.)
Jason, can you
share your app? zip it up and pass it to us? I'll be happy to
check it out myself. I'd like to examine the stack manually and see
about setting up break points on the stack itself.
This
rsCheckData, is it on the stack or is it a register? If it's on the
stack, check it's address each time you find it corrupted, if it's always at
the same address put a memory breakpoint for when that memory == 0x00000001 to
break. Your app will run a lot slower, but eventually you should catch
the culprit.
Yeah this might work since the rsCheckData resides
on the stack IIRC (didn't check the asm again.)
But the thought is one thing, the deed
another, and the idea of the deed still another. The wheel of causality
does not roll between them.
-Thus Spoke Zarathustra, F. W.
Nietzsche |
|
_______________________________________________
msvc mailing list
[email protected]
See http://beginthread.com/mailman/listinfo/msvc_beginthread.com for
subscription changes, and list archive.
