CString access violations!

Hi,

I'm having access violation problems with CString. Checking the boards, I discovered that I do not suffer alone. A solution recommended was to type cast to LPCTSTR before assigning the new CString value.

I'm still getting access violation problems, though in a new spot. It now appears in the red-line in the following code.

void CString::AssignCopy(int nSrcLen, LPCTSTR lpszSrcData)
{
AllocBeforeWrite(nSrcLen);
memcpy(m_pchData, lpszSrcData, nSrcLen*sizeof(TCHAR));
GetData()->nDataLength = nSrcLen;
m_pchData[nSrcLen] = '\0';
}

The strange thing is, that both before and after the memcpy, the m_pchData points to garbage. I did initialize it.

Hope this info isn't too vague. Hope someone else has suffered through similar problems and has an idea.

Mat.

There are two possible causes:

1) CString bug:

There is a bug in CString that prevents the correct synchronization of the reference counter which tracks which CString object actually owns the character array data.

Whenever you assign one CString object to another you assume it is copying the data when really it's only referencing the original string and incrementing it's reference counter.

If the original string is subsequently destroyed, and then the second string referencing the common data needs to access that data, sometimes it's gone.

This leads to weird problems as you describe rather than a more predictable outcome that you might expect.

Example:

Code:

---

CString Original;

if(1)
{
    CString LocalString = "My String";

    Original = LocalString; // causes LocalString reference to increase

}

// LocalString is now destroyed because it's out of scope

printf("This should work: %s\n", Original);

---

There are occasions where the above will not work because the data has already been destroyed. This is a simple example that will likely work every time, but for sure there are some occasions this does not work (I don't know the fundamental reason).

You can avoid this problem by casting:

Original = (LPCTSTR)LocalString;

This causes the Original CString object to copy the raw data from LocalString without playing with the references.

2) You've toasted the CString class

If you destroy CString, all instances of CString become mutually toasted, then it's just a question of which one gets called next before things blow up (again, in an unpredictable way).

Example:

Code:

---

CString MyString "Hello World!";
strcpy(MyString, "Oops, this is gonna leave a mark!");

---

This causes very strange things to happen the next time you go to use any CString object (probably elsewhere in the code).

Therefore, you need to figure out which string assignment is causing you problems. This is an extremely tedious task that I've had to do myself a couple of times (so I feel your pain).

All I can say is that if you check and use casting every instance where you are using the CString equal operator, you will absolutely make this problem go away. Obviously problem 2 described above is just plain wrong, and should be fixed.

One of these days I might try and track down this nasty critter of a bug.

Hope this helps,

- Nigel

Quote:

---

Originally posted by Mat C
Hi,

I'm having access violation problems with CString. Checking the boards, I discovered that I do not suffer alone. A solution recommended was to type cast to LPCTSTR before assigning the new CString value.

I'm still getting access violation problems, though in a new spot. It now appears in the red-line in the following code.

void CString::AssignCopy(int nSrcLen, LPCTSTR lpszSrcData)
{
AllocBeforeWrite(nSrcLen);
memcpy(m_pchData, lpszSrcData, nSrcLen*sizeof(TCHAR));
GetData()->nDataLength = nSrcLen;
m_pchData[nSrcLen] = '\0';
}

The strange thing is, that both before and after the memcpy, the m_pchData points to garbage. I did initialize it.

Hope this info isn't too vague. Hope someone else has suffered through similar problems and has an idea.

Mat.

---

This doesn't mean there is a problem with CString. What you showed is just a symptom to a problem that may not have anything to do with CString. You can screw up any object if your coding is faulty, i.e. overwrite memory, calling delete twice on the same dynamic object, whatever. No class is invulnerable to coding that has memory bugs, faulty ccoding, or use undefined behavior. I highly doubt that if you are using CString correctly, CString would have a bug.

You need to show exactly how you are manipulating these CString objects in your program. Also, it would be helpful if you can mimic, with a very small, compilable example, of what you are doing with the CStrings and see if you can duplicate the error. There are too many posts that claim that CString has these bugs but always all of these problems have been found to be other aspects of the program that is affecting the CStrings. and not bugs with CString.

Regards,

Paul McKenzie

I wouldn't be surprised if there is something wrong with my code. I've never been very good at memory management, plus this problem only started appearing after I started using the CMap template, and trying to retrieve objects from the map.

That is a good idea about writing a smaller version to duplicate the prob. I will get on that.

Oh, and btw, I DID do the LPCTSTR type-cast on all assignments for that string, and still I am having grief.

Thanks for the help,
I'll be back with some code.

Mat.

Well, trying to reproduce the bug led me to the error of my ways.

Basically, the problem was caused by a little function like this one:

CNewInfo* CTheDocument::GetNewInfo()
{
CDataSet oDataSet;
m_DataMap.Lookup(m_strCurKey, oDataSet);

return &oDataSet.m_NewInfo;
}


As is now obviously the problem, oDataSet goes out of scope at the end of this function, and the pointer in the calling method is left pointing to an address which is no longer valid. What threw me for a loop was that I could manipulate the integer members of CNewInfo from the pointer in the calling function. Since re-assigning the CString member caused me grief, I automatically assumed he was the problem.

What I was trying to do by this function was to get a reference directly to the CNewInfo object in the DataMap, so that I wouldn't have to do a SetAt() afterwards. But it seems that CMap is too tight of a class to let me be sloppy with it.

Out of curiosity though, would anyone know if it is possible to return a pointer to a members of a class using CMap as a template?

Thanks for the help. Maybe one day I'll be able to give advice too.

Mat.

You are returning a reference to a local variable. This is an error in C++ (run-time error, not compiler error). The "fools gold" is thinking that you can manipulate the return value -- sooner or later you would have caused a memory overwrite, GPF or something else undefined. You should never return a reference to a local object, it's that simple.

The thing you need to figure out is to make sure your map is not destroyed, i.e. it is a global or it is a member of an object that doesn't go out of scope and destroyed. Then and only then can you return references to the object from a function.

Regards,

Paul McKenzie

Quote:

---

Originally posted by Mat C
Hope this info isn't too vague. Hope someone else has suffered through similar problems and has an idea.

---

I hope you don't mind me commenting on one thing that I think was not clear. The code you posted appears to me to be MFC source code, not your source code. However that was not made clear.

Quote:

---

Originally posted by NigelQ
There is a bug in CString that prevents the correct synchronization of the reference counter which tracks which CString object actually owns the character array data.

---

I think many of us would be very interested in any such bugs. If such a bug exists I am quite surprised there is not more discussion of it. I agree with Paul that any such problems are probaly explained by improper use of CString and such things.

I know it sounds like the error was in my code, and if that were the case I'd happily admit it, although one instance of this problem always comes to mind where I checked every instance of where I was using CString objects, adjusting each one to force the cast.

I saw no problems with the code as I checked all of these references, but after performing the casting trick, everthing worked. Ok, I might have missed something while I was checking, but I'd seen this problem before, and was looking for the culprit.

I am aware of several occasions where this problem has happened to others on my team, where after using the casting trick, everything worked fine.

Bizarre !

Anyway, all this hot air is going to force me to really get to the bottom of the issue the next time I see it (or think I see it :D )

- Nigel