I've just realized that the title may be kind of misleading. so I'm rewriting this part.
Basically I have added a new method which holds the following 'functions' in the title, and I believe its causing my program to break at a very strange point in my 'UpdateSentence' method.
Here is the method I have just recently added "setFPS" in my Text class.
bool Text::setFPS(int fps, ID3D11DeviceContext* deviceContext)
{
char tempS[16];
char fpsS[16];
float red = 1.0f;
float green = 1.0f;
float blue = 1.0f;
bool r;
if(fps > 9999) //Truncate the fps
{
fps = 9999;
}
_itoa_s(fps, tempS, 10);
strcpy_s(fpsS, "FPS: ");
strcat_s(fpsS, tempS);
/*
if(fps >= 60) //if FPS is above or equal to 60 set text colour to green
{
red = 0.0f;
green = 1.0f;
blue = 0.0f;
}
if(fps < 60) //if FPS is below 60 set text colour to yellow
{
red = 1.0f;
green = 1.0f;
blue = 0.0f;
}
if(fps < 30) //if FPS is below 30 set text colour to red
{
red = 1.0f;
green = 0.0f;
blue = 0.0f;
}
*/
r = UpdateSentence(sentence3, fpsS, 20, 20, red, green, blue, deviceContext);
if(!r)
{
return false;
}
return true;
}
Now the application isn't breaking/crashing at this point, it's breaking at another method called "UpdateSentence" which you can see in the screenshot here:
Here is the break I'm getting, it seems to be happening with adding colour to the function and I have no idea why its playing up now when it previously wasn't.
Also if someone needs to see more code just ask and I can show
If someone could shine some light on this I would be greatful
On 32-bit Windows, the maximum user addressable memory is 3GB, with the top 1GB of the virtual address space reserved for the kernel. If your pointer value is 0xC0000000 or higher then it can't be a legal pointer value. More specifically OxCDCDCDCD is MSVC's debug fill pattern for uninitialized memory. If you see a pointer error involving that address it generally means that you are accessing uninitialized memory, which since the debugger is identifying sentence's value as 0xCDCDCDCD that probably means that you either don't initialize sentence correctly when creating your object or that you are calling a member function on an invalid object pointer. Either way the sentence pointer isn't valid.
On 32-bit Windows, the maximum user addressable memory is 3GB, with the top 1GB of the virtual address space reserved for the kernel. If your pointer value is 0xC0000000 or higher then it can't be a legal pointer value. More specifically OxCDCDCDCD is MSVC's debug fill pattern for uninitialized memory. If you see a pointer error involving that address it generally means that you are accessing uninitialized memory, which since the debugger is identifying sentence's value as 0xCDCDCDCD that probably means that you either don't initialize sentence correctly when creating your object or that you are calling a member function on an invalid object pointer. Either way the sentence pointer isn't valid.
I see, but it was working previously, before I added the "setFPS" function, but if thats the case, is there anyway of getting round it?
Now the application isn't breaking/crashing at this point, it's breaking at another method called "UpdateSentence" which you can see in the screenshot here:
Then why don’t you show the code for UpdateSentence()?
Also, sentence3 is garbage when it is passed to UpdateSentence(). I assume it is a member of the Text class.
Naming conventions such as m_ would go a long way to help people realize from where variables are coming.
It needs to be initialized—this has nothing to do with the functions listed in the topic.
L. Spiro
I restore Nintendo 64 video-game OST’s into HD! https://www.youtube.com/channel/UCCtX_wedtZ5BoyQBXEhnVZw/playlists?view=1&sort=lad&flow=grid
strcpy_s(fpsS, "FPS: ");
I am not sure what strcpy_s does, but if it's anything like strcpy, you are using fpsS uninitialized.
strcpy_s(char* dest, const char* src); works like strcpy but it will fail (I think with an exception? maybe just a windows error) if it would cause an overrun.
As for the error, it looks like that address is actually 0xCDCDCDE1, which suggests that somewhere you're adding 20 to an uninitialized pointer rather than initializing it.
Just put a conditional breakpoint at the start of the function there that breaks if the pointer value is 0xCDCDCDE1 and then look at the stack to see where it's coming from.
void hurrrrrrrr() {__asm sub [ebp+4],5;}
There are ten kinds of people in this world: those who understand binary and those who don't.
