• Advertisement
Sign in to follow this  

STL string problems

This topic is 4175 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

I've had a strange error crop up recently with STL strings. It seems as though strings are getting 4 bytes of junk data inserted into the beginning of it after passing it as a parameter. For example: Function Prototype: void OpenFile(const std::string& strFile) ; Call: OpenFile("SomeFile.txt") ; After stepping through the debugger I can see that 'strFile' contains a string with contents like this: IIIISomeFile.txt (the 'I's all have a little carat over them). I've narrowed the problem down to the string class because if I change std::string& to char* everything works fine. Has anyone seen this before? I'm 99% certain it's not an ASCII/UNICODE problem but I'm not ruling anything out at this point.

Share this post


Link to post
Share on other sites
Advertisement
My guess would be that it's the size of the sting. Is the 4 bytes 12 (or possibly 13) in your example?

Share this post


Link to post
Share on other sites
no, the one that I'm looking at is 15 characters. But it doesn't matter, they all seem to be doing that now....

Share this post


Link to post
Share on other sites
How are you using the string? Are you calling s.c_str() to pass it to an fstream object? If not, I'd be inclinded to agree that it is part of the internal representation of the string.

Share this post


Link to post
Share on other sites
Don't worry about that, I'm quite sure it's part of the internal representation, perhaps some uninitialised memory in the block the string is part of? I get that too when stepping through with the debugger, but everything still works fine and to the outside world there's no trace of the oddly accented Is. So, just don't worry, it's not a problem :)

Share this post


Link to post
Share on other sites
I would agree with you except that it crashes while trying to assign one stl string to another stl string. If everything was working the way it was supposed to I wouldn't worry about it, but as it stands I get some major assertions along the way.

Share this post


Link to post
Share on other sites
Try showing a minimal, but complete, code sample that demonstrates your problem. Otherwise all we've got is guesswork to go on.

Share this post


Link to post
Share on other sites
It's a basic memory problem in the string.


std::string g_strSomeString = "" ;

void AssignText(const std::string& strText)
{
g_strSomeString = strText ;
}

int main()
{
AssignText("Foo") ;

return 0 ;
}



After executing the above code you would expect that 'g_strSomeString' would contain the value of "Foo". My problem is that during the execution of the above code, 'strText' in 'AssignText' contains "IIIIFoo" and g_strSomeString contains "" because the data at the beginning of 'strText' is junk data. Any Ideas?

Share this post


Link to post
Share on other sites
What compiler are you using? Your code sample seems to work just fine under MSVC 2003 and gcc 3.4.4.

Share this post


Link to post
Share on other sites
  • What happens if you actually print out the contents of g_strSomeString before and after the call to AssignText?

  • What are your compiler settings?
Σnigma

Share this post


Link to post
Share on other sites
Okay, now this is wierd. If I call 'c_str()' on the string it gives me back the proper information. So it looks like the problem is limited to working with just the stl string. For some reason I still can't assign a string to another string.

Share this post


Link to post
Share on other sites
Well, I know the problem exists in my project. I've tried a sandbox application and that works fine.

I'm using standard debug compile and linker settings. I don't really have the option of creating the project fresh because of the size of the codebase (34k lines).

It's unlikely that any of you are going to be able to help me debug the problem. However, I do appreciate the help and if anyone has seen an error like this before, any information you have could be helpful.

Thanks...

Share this post


Link to post
Share on other sites
Quote:
Original post by jkleinecke
Well, I know the problem exists in my project. I've tried a sandbox application and that works fine.

This almost certainly means you have memory corruption in your project. Set a data watch on the memory which appears to be corrupted to find out where it's being modified.

Σnigma

Share this post


Link to post
Share on other sites
While I don't doubt the memory issue, I don't really think it's a corruption problem. The problem just appeared in the codebase and it first shows up on the first memory allocation that takes place. It's definitely an issue with stl string memory allocation.

Share this post


Link to post
Share on other sites
I see Í in the MSVC debugger all the time. It means the memory wasn't initialized. In debug builds, everything is initialized to the hex value '0xCDCDCDCD'. 'CD' happens to be the ascii code for the character Í.

Share this post


Link to post
Share on other sites
Ah, that makes sense. What doesn't make sense is why all my strings start 4 bytes into the string buffer...

Share this post


Link to post
Share on other sites
Could you possibly have incremented a value one-past-the-end of an array of int* values, such that the first 4 bytes of the string object got incremented by sizeof(int) == 4, where those bytes happen to represent the pointer-to-data in your compiler's std::string implementation? :s

Share this post


Link to post
Share on other sites
While that's always a possibility, it's not likely to be the problem. I create a string to pass into my engine initialization, it's the first allocation and it's immediately wrong. My first guess was that it was a buffer overrun.

I have found a way around the problem though. I have my own memory manager and STL Allocator that plugs into the memory manager. The only STL type I hadn't wrapped was string so I went ahead and did that one as well. Strings are a little bit harder to get right, so it took some work. But after taking all weekend to implement it, I haven't seen that problem. Anyway, thank for all your help.

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement