Prev: TreeCtrl and Images
Next: How to get crash dump when a unhandled CException is thrown by a MFC app
From: Tom Serface on 6 Jan 2010 18:36
I wonder if your getting a referencing problem. CString attempts to not
create new values if it thinks it can use the same one for multiple
occurrences. I've been caught by this before. I usually force the issue by
using the LPCTSTR operator like:

CString cs = (LPCTSTR) csValue;

Might be worth a try anyway.

Tom

"Frank Perry" <FrankPerry(a)discussions.microsoft.com> wrote in message
news:4B4C1346-2741-4FB2-B12A-0CBF0961302D(a)microsoft.com...
> Howdy,
>
> I'll try and cover several questions.
>
> The program is not Unicode.
>
> The CString in the case here could be generated one of serveral ways. The
> most likey is:
> const char *DefOperators[] =
> {
> "OR",
> "AND",
> "ADJ",
> "NEAR",
> "WITH",
> "SAME"
> };
>
> CString ValidateDefOperator(CString Value)
> {
> Value.MakeUpper();
> int Size = sizeof(DefOperators)/sizeof(DefOperators[0]);
> for(int i=0; i<Size; i++)
> if(DefOperators[i] == Value)
> return Value;
> return "OR";
> }
> When it comes from some other source, it will be processed here so the end
> result would be the same.
>
> I can't trace it because it is a rare occurrence. I'm afraid that logic
> is
> about all I can apply to the problem.
>
> I don't see instances of GetBuffer applied to the string in question. The
> data is a class variable. If something is clobbering the string, it will
> be
> almost impossible to sort out of the hundreds of C++ files that make up
> the
> code.
>
> One reason for asking about this is I had a similar problem show up when a
> CString was being returned from or Oracle ODBC driver. That would
> sometimes
> return a bad length for the string in a field of the rowset. It was
> returned
> from the driver with a problem before anything in the program itself
> touched
> it. I was wondering if this was similar.
>
> The string itself is corrupted because the serialized data for it is FF FF
> FF 02 00 00 DD, which indicates it was returned to the serialize string
> function as 0xDD000002 bytes long.
>
> --
> Frank Perry
> LavaLeaf Software
>
>
> "Frank Perry" wrote:
>
>> Howdy,
>>
>> I'm having a problem with CString. Rarely but too often, GetLength
>> returns
>> the wrong length. A recent example is a CString "OR" returned a length
>> of
>> 0xDD000002. As you could guess, this caused Serialize to have a
>> heartattack.
>>
>> Has anyone seen this kind of problem before and have an idea of the cause
>> and of a solution?
>>
>> --
>> Frank Perry
>> LavaLeaf Software

From: Giovanni Dicanio on 7 Jan 2010 04:19
"Tom Serface" <tom(a)camaswood.com> ha scritto nel messaggio
news:OWdPGkyjKHA.1864(a)TK2MSFTNGP05.phx.gbl...

> I wonder if your getting a referencing problem. CString attempts to not
> create new values if it thinks it can use the same one for multiple
> occurrences.

I think CString is a very robust class.

I would think that string corruption originated in some other places in OP's
code (maybe some buffer overrun).

Giovanni


From: Goran on 7 Jan 2010 04:37
On Jan 6, 11:27 pm, Frank Perry <FrankPe...(a)discussions.microsoft.com>
wrote:
> The string itself is corrupted because the serialized data for it is FF FF
> FF 02 00 00 DD, which indicates it was returned to the serialize string
> function as 0xDD000002 bytes long.

So it's not a GetLength error, but serialization error. OK, I'll put
my serialization master hat on now...

What I can say is: your file is borked and there's nothing you can do
about that. Best approach by far is to find the source of the problem,
and that will be inspection of the "save" path for said files.

At load time, when you get bad data, you are already dead.
Serialization is, in principle, an all-or-nothing proposition, so
attempts to salvage stuff at load time are __very difficult__, and, in
general case, doomed to fail.

Goran.
From: Anthony Wieser on 7 Jan 2010 06:35
It may of course be the deserialization code of some object somewhere before
it in the stream that's at fault instead.

Anthony Wieser
Wieser Software Ltd


"Goran" <goran.pusic(a)gmail.com> wrote in message
news:a9de3f6a-20f5-49bf-ba59-e5b16c78e756(a)m26g2000yqb.googlegroups.com...
On Jan 6, 11:27 pm, Frank Perry <FrankPe...(a)discussions.microsoft.com>
wrote:
> The string itself is corrupted because the serialized data for it is FF FF
> FF 02 00 00 DD, which indicates it was returned to the serialize string
> function as 0xDD000002 bytes long.

So it's not a GetLength error, but serialization error. OK, I'll put
my serialization master hat on now...

What I can say is: your file is borked and there's nothing you can do
about that. Best approach by far is to find the source of the problem,
and that will be inspection of the "save" path for said files.

At load time, when you get bad data, you are already dead.
Serialization is, in principle, an all-or-nothing proposition, so
attempts to salvage stuff at load time are __very difficult__, and, in
general case, doomed to fail.

Goran.

From: Frank Perry on 7 Jan 2010 10:09
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.)

--
Frank Perry
LavaLeaf Software


"Goran" wrote:

> On Jan 6, 11:27 pm, Frank Perry <FrankPe...(a)discussions.microsoft.com>
> wrote:
> > The string itself is corrupted because the serialized data for it is FF FF
> > FF 02 00 00 DD, which indicates it was returned to the serialize string
> > function as 0xDD000002 bytes long.
>
> So it's not a GetLength error, but serialization error. OK, I'll put
> my serialization master hat on now...
>
> What I can say is: your file is borked and there's nothing you can do
> about that. Best approach by far is to find the source of the problem,
> and that will be inspection of the "save" path for said files.
>
> At load time, when you get bad data, you are already dead.
> Serialization is, in principle, an all-or-nothing proposition, so
> attempts to salvage stuff at load time are __very difficult__, and, in
> general case, doomed to fail.
>
> Goran.
> .
>
First  |  Prev  |  Next  |  Last
Pages: 1 2 3 4
Prev: TreeCtrl and Images
Next: How to get crash dump when a unhandled CException is thrown by a MFC app