I haven't been able to use Application Verify. It seems to block my
to the database. I haven't had a chance to see why or how but when I have
"Joseph M. Newcomer" wrote:
0xDD is the byte used to represent free storage in the debug heap (see
crt\src\dbgheap.c
in the VC directory, for example). So if one of these bytes were copied
accidentally into
the space, for example, by using a dead pointer, who knows what is going
to happen? If a
pointer which used to point to a structure is used to obtain a byte, you
might get 0xDD,
and if another pointer to what used to point to another structure is used
to store it, and
that pointer now points to what is now a CString, well, that's certain
death, and the data
you see could result. Note that sometimes the data might be a 0 in which
case a 0
overwrites a 0, so the bug only shows up when the overwritten data is
nonzero.
Try running under the Application Verifier with all possible storage
tests turned on. It
might show up something.
joe
On Thu, 7 Jan 2010 07:09:01 -0800, Frank Perry
<FrankPerry@discussions.microsoft.com>
wrote:
Howdy,
I looked at the serialization code for serializing a CString. It gets
the
length from CString and based on that length writes out the length of
the
length (if that makes sense) in the form of a mask before adding the
string.
From that, I think the GetLength is the problem. Based on the length,
it
prefaces the length with either no bytes if the length is 0 - 0xfe, or
FF if
it's 0xff to 0xfffe, etc. It prefaces the string length with 0xff 0xff
0xff
so it clearly believes the length is 0xDD000002 (e.i. requiring 4 bytes
to
express).
I am not sure what I think about the buffer overrun. On the one hand,
it is
an obvious possibility that something else is clobbering the data. But
on
the other hand, almost everything we write is a string and 0xDD isn't in
the
normal character set. If it was something like 0x41 or 0x20 it would
make
much more sense.
I am not familiar with the format of a CString but is the length
someplace
where it could be clobbered by an overrun while leaving the actual 2
inplace
and also leave enought of the rest of the header to still function as a
string? Assuming it's 'little endian' I would think the 2 would have
been
clobbered before an overwrite would leave an 0xdd three bytes deeper in
the
CString header.
I find the idea of a copy function going bad hopeful. (If only because
I
can change that quickly and see what happens.) In my experience,
copying a
string with a bad length will result in the new string being just as bad
as
the old one. It copies by the string's stated length and not the actual
length. (My ODBC Cstring problem was correctable by saving a new string
with
LockBuffer which stopped at the first 0x00 and not the GetLength value.)
Joseph M. Newcomer [MVP]
email: newcomer@flounder.com
Web: http://www.flounder.com
MVP Tips: http://www.flounder.com/mvp_tips.htm
.