hipswich

I am struggling with a bug that seems to be related to a string use. In the process, the debugger shows something very puzzling.

The file atlsingstr.h in directory atlmf\include defines the class CSimpleStringT.

I set a break point at Attach() line highlighted in red in its following function:

CSimpleStringT( __in const CSimpleStringT& strSrc )

{

CStringData* pSrcData = strSrc.GetData();

CStringData* pNewData = CloneData( pSrcData );

Attach( pNewData );

}

Here are contents of the variables that pulzzle me greatly:

strSrc = "IC communication lost for greater than 30.0 seconds"

pSrcData = 0x0322d0a8 {pStringMgr=0xfeeefeee nDataLength=-17891602 nAllocLength=-17891602 ...}

pNewData = 0x0322d0a8 {pStringMgr=0xfeeefeee nDataLength=-17891602 nAllocLength=-17891602 ...}

Apparently something is wrong. Could anyone offer some clue

Thanks in advance




Re: Visual C++ Language CSimpleStringT error

Holger Grund

There's on thing that suggests you have bad pointers: 0xfeee is a special value. Some heap functions (both Windows, and the VC++ debug CRT) fill blocks with special values to help with debugging. IIRC 0xfeee suggests that the block is part of a heap reserved area, which has not yet been allocated by user code.

Since I don't have a VC++ installation on this box I can't really take a look at the headers. But I seem to recall, CStringT has a data member to the character buffer (so you can still pass CString objects directly to the ellipsis where a const TCHAR* is expected) and that buffer is preceeded by additional information about the string.

Are passing CString objects across module boundaries with VC6 code involved E.g. passing a VC6 constructed CString to a VC 7+ consumer would probably have such effects.

I'd take a look at where strSrc comes from and then investigate why its data is skrewed up.

-hg





Re: Visual C++ Language CSimpleStringT error

hipswich

Thanks, Holder.

Though I still do not understand why pSrcData has a bad pointer while strSrc looks fine, I have found the problem of my code - loose synchronization.

To put a long story short, I have two threads - one modifying the string and the other reading or copying it. It is the copying part that caused the problem. Now I expanded the use of the CCriticalSection synchronization object for the object containing the string to every possible spot with the potential of thread conflict. The program seems to be working fine now.

The project started with VC6, then migrated to VC7 (VS 2003) and VC8 (VS 2005).

It would save me a lot of time if the debugger could stop at the line of my code instead of ATL/MFC code where the exception happens.







Re: Visual C++ Language CSimpleStringT error

anb@

I am also facing the same issue. I didn't understand your solution. Could you please explain the solution




Re: Visual C++ Language CSimpleStringT error

hipswich

There are two issues involved.

1. The debugger does not stop at my code that generates the error but stops at ATL library code related CSimpleString and cannot be traced back to my code. My code does not use CSimpleString directly. This is what my original post was asking about. I do not know how to address this issue.

2. The problem of my code was there are two threads accessing a structure's CString member. I used CCriticalSection to prevent the two threads from accessing it simultaneously, but I missed some spots resulting in one thread copying the member while another thread modifying it once a while. The solution is to expand the use of the CCriticalSection instance to every reference of the CString object.







Re: Visual C++ Language CSimpleStringT error

anb@

Thanks for your details. The problem happens when we call an activeX control method(whose threading model is 'Apartment') from another activex control(whose threading model is 'Single'). Both the control runs in Internet explorer. Is there any limitation in using activex control in IE whose threating model is 'Single'

Thanks in advance.