Prev: TreeCtrl and Images
Next: How to get crash dump when a unhandled CException is thrown by a MFC app
From: Tom Serface on 12 Jan 2010 12:12
Hi Frank,

You could try switching out to a std:string instead and see if you get a
similar issue. That may not be an easy thing to do, but it would prove
whether it's CString's fault or the fault of something in your code. I use
CString a LOT with absolutely not problems, but that doesn't prove that
there are none. As I mentioned before I do use a specific cast (LPCTSTR) on
occasion to force CString to create a new copy since I've found the
reference counter to have problems on occasion, but other than that it works
as advertised. If you could switch out to a different kind of string and
you still have the issue then ...

Tom

"Frank Perry" <FrankPerry(a)discussions.microsoft.com> wrote in message
news:3982A5BD-AA09-4B89-BBE1-F838AC61501C(a)microsoft.com...
> Howdy,
>
> I haven't been able to use Application Verify. It seems to block my
> access
> to the database. I haven't had a chance to see why or how but when I have
> my
> program listed in it, the program failes to return data from the ACE dll
> that
> interacts with the database.
>
> --
> Frank Perry
> LavaLeaf Software
>
>
> "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(a)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(a)flounder.com
>> Web: http://www.flounder.com
>> MVP Tips: http://www.flounder.com/mvp_tips.htm
>> .
>>
From: Frank Perry on 12 Jan 2010 17:07
Howdy,

I wish I could create test versions but that isn't in the cards. There are
about 6000 people who use the program. It's a government contract and we are
not allowed by contract to install anything that isn't run through the full
FQT process and pushed to all the workstations at once. The problem is rare
so ofcourse it never happens on my test machine.


--
Frank Perry
LavaLeaf Software


"Hector Santos" wrote:

> Frank Perry wrote:
>
> > ....
> > 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.
>
>
> In general when rare and intermittent things like this rear its head,
> it means its a PDE - programming design error.
>
> It could be buffer overflow, underflow or whatever, a corruption is
> occurring somewhere. This basically means, you need to isolate your
> code, black box it and make sure its perfect in isolated testing and
> if you still have problems when you plug it back into your
> application, then you have a PE somewhere. Its that plain and simple. :)
>
> Divide and conquer is one way to get to this problems. A good heap
> manager tool may help too.
>
> Happy Hunting!
>
> --
> HLS
> .
>
From: Tom Serface on 12 Jan 2010 17:19
Man, I can say, been there done that... I don't know how to solve the
problem, but I can commiserate.

Tom

"Frank Perry" <FrankPerry(a)discussions.microsoft.com> wrote in message
news:B62D058D-F26A-4168-8B51-EE4816415D8A(a)microsoft.com...
> Howdy,
>
> I wish I could create test versions but that isn't in the cards. There
> are
> about 6000 people who use the program. It's a government contract and we
> are
> not allowed by contract to install anything that isn't run through the
> full
> FQT process and pushed to all the workstations at once. The problem is
> rare
> so ofcourse it never happens on my test machine.
>
>
> --
> Frank Perry
> LavaLeaf Software
>
>
> "Hector Santos" wrote:
>
>> Frank Perry wrote:
>>
>> > ....
>> > 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.
>>
>>
>> In general when rare and intermittent things like this rear its head,
>> it means its a PDE - programming design error.
>>
>> It could be buffer overflow, underflow or whatever, a corruption is
>> occurring somewhere. This basically means, you need to isolate your
>> code, black box it and make sure its perfect in isolated testing and
>> if you still have problems when you plug it back into your
>> application, then you have a PE somewhere. Its that plain and simple. :)
>>
>> Divide and conquer is one way to get to this problems. A good heap
>> manager tool may help too.
>>
>> Happy Hunting!
>>
>> --
>> HLS
>> .
>>
From: Frank Perry on 12 Jan 2010 17:45
Howdy,

I wouldn't be surprised that there is a problem with the DLL we use to
access the database. (That has to be taken with a grain of salt as the DLL
isn't _our_ DLL and would be someone else's problem, so I'm biased.)

I will continue to try and get Application Verify to run. But, the cycle of
juggling priorities is moving away from this problem, so it may be a few days
before I get it worked out.

--
Frank Perry
LavaLeaf Software


"Joseph M. Newcomer" wrote:

> Hmmm...that's interesting, and may already be symptomatic of a problem. I've not used
> databases, so don't know about potential problems that might exist.
> joe
>
> On Mon, 11 Jan 2010 10:09:01 -0800, Frank Perry <FrankPerry(a)discussions.microsoft.com>
> wrote:
>
> >Howdy,
> >
> >I haven't been able to use Application Verify. It seems to block my access
> >to the database. I haven't had a chance to see why or how but when I have my
> >program listed in it, the program failes to return data from the ACE dll that
> >interacts with the database.
> Joseph M. Newcomer [MVP]
> email: newcomer(a)flounder.com
> Web: http://www.flounder.com
> MVP Tips: http://www.flounder.com/mvp_tips.htm
> .
>
First  |  Prev  | 
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