Problem with String2D in SFML 1.6?

[diRe]

Hello,

it occurs to me that I have got a nasty problem with String2D.

Whenever the text length of the String2D object is greater than 15, the program crashes when reading the text from the Text property (the problem seems to lie in the layer between the .Net and C libraries). The proper error message would be

Es wurde versucht, im geschützten Speicher zu lesen oder zu schreiben. Dies ist häufig ein Hinweis darauf, dass anderer Speicher beschädigt ist.
   bei SFML.Graphics.String2D.sfString_GetText(IntPtr This)
   bei SFML.Graphics.String2D.get_Text()

As one might see, this is German. The translation would be something like "It was tried to read or write protected memory. This often is caused by corrupted memory." More or less at least

Consider the following code:

Code: [Select]

String2D str = new String2D();
str.Text = "1234567890123456"; // str.Length == 16
string a = str.Text; // Crash

What makes me a bit surprised is the fact, there is no problem at all, unless the String2D.Text.Length is greater 15. Also, this only happens in the get Element of the Text property. The text can be set accurate and is also properly displayed, when invoked by a Draw command.

Now I am wondering whether this is a known bug or feature (?) or am I simply missing something to config? I even tried to change the standard font to something else, as I read there was a problem with the standard font (I image that had something to do with SFML 1.6 as I stumbled upon that problem, when I was programming in C++).

Note: I am currently using Windows Vista, Visual Studio 2008 Prof. with SFML.Net 1.6.

[Laurent]

This is really weird. I have no idea why it crashes.

[diRe]

Yeah, well. As much as I appreciate your answer... That does not help me at all

I just ran the same lines of code on my Linux machine and the outcome was the same: Crashing when invoking the get part of the Text attribute. So it does not seem to be a Windows-only problem.

Your reaction states, you did not know about it and it seems, this is not a local problem only I ran into. So I would be really happy if you happen you solve this "bug". If you cannot find it or you do not have enough time to look for it, I have to create a little work-around, which of course then would work. But it would not be the best solution

I have read in another thread that there seemed to be a problem with fonts. I did not read it completely, but I read the fact, there was (regarding the error message) a problem with the get-Text property, representing the same error I ran into.

Nevertheless thank you for reading this and providing us with a great library!

[Laurent]

I know my answer doesn't help you, but at least you know that I'm aware of the problem and that I don't have the time to fix it now.

So go on with your workaround if you have one, and post an issue on the new task tracker on github as soon as it is available (should happen in a few days).

[diRe]

Okay,

I guess (more or less) I found the problem.

After taking a look at the C SFML Code, I noticed sfString_GetText returns a const char*. On the C Code level, everything was fine. So the problem occurs, when .Net tries to convert the C const char* to the .Net String type. My guess is, .Net just "copies" the first 16 characters, which then results in the terminating \0 character of the const char* to be skipped, if the String2D.Text length is at least 16. Trying to determine the string length by looking for the terminating \0, .Net goes over its allowed limits and enters protected memory, which then results in an Exception being thrown.
Well, at least that is my guess.

To solve this, I modified the .Net code of String2D:

Code: [Select]


public string Text
{
    get
    {
        return Marshal.PtrToStringAnsi(sfString_GetText(This));
    }
    // ...
}
// ...
[DllImport("csfml-graphics"), SuppressUnmanagedCodeSecurity]
static extern IntPtr sfString_GetText(IntPtr This); // Replaced the return type from string to IntPtr

Now this seems to work, I tested it and got no more crashes.

Of course, this does still not solve your TODO comment with Unicode