Jump to content
  • Advertisement
Sign in to follow this  
spraff

sprintf_s causes a crash

This topic is 3659 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

Hi there. I'm using Visual Studio 6 and the following snipped causes a crash
char buffer[50];
sprintf_s(buffer,50,"%d",value);

After the second line executes the "this" pointer has the value of 0xfefefefe, i.e. it has been deleted. How come?

Share this post


Link to post
Share on other sites
Advertisement
Possibly this pointer have unknown value (0xfefefefe) before you execute your sprintf_s function. So "this" is deleted somewhere before you enter function.

Share this post


Link to post
Share on other sites
Nope, I stepped through it in a debugger. This code is in a member function, by the way. "this" is defined before, but not after, the sprintf_s call

Share this post


Link to post
Share on other sites
I don't think the sprintf has anything to do with it. My guess is you're calling this method in an object that has already been deleted. If you're sure it's the sprintf_s, though, you can easily set your buffer to all nulls and take out the sprintf_s line. If this is still fefefefe'd then it's not the sprintf.

(Obligatory: You should use STL strings if possible.)

Share this post


Link to post
Share on other sites
Show us more surrounding code. Also, could you paste the following line once before the sprintf_s and once after and tell us what it printfs?

printf("%p\n", this);

Oh and since you're using a C++ compiler, you might as well write in C++:

#include <sstream>
#include <string>

// ...

std::stringstream ss;
ss << value;
std::string buffer = ss.str();

Share this post


Link to post
Share on other sites
Quote:
Original post by spraff
Hi there. I'm using Visual Studio 6 and the following snipped causes a crash
I'm really not surprised. Visual C++ 6.0 is a terrible, terrible compiler which is over a decade old, came out before the first C++ standard (Meaning it's technically not a C++ compiler), doesn't optimise well at all, fails with templates and has a horrific, buggy STL implementation.

Visual Studio 2008 Express would be a much better choice. It's free, does almost everything that VC6 does (And nothing that should matter for most developers), and is much more stable and produces much better code.

Share this post


Link to post
Share on other sites
Quote:
Original post by spraff
Replacing sprintf_s with sprintf prevents the crash.

Oh, and I'm using VS 2008, not VS 6, sorry.


Show some more code? What type is value?

Share this post


Link to post
Share on other sites
Quote:
Original post by spraff
Replacing sprintf_s with sprintf prevents the crash.
That's not really a good thing - the code you had should work, you've probably just hidden the real bug.
I'd suggest putting the sprintf_s() back and tracing into the function to see when the this pointer is changed (You can set a data breakpoint on it if it's easier).
You could also try doing a clean build in case the compiler is screwing something up.
Also, is this a debug build? Release builds do all sorts of strange things when you debug them.

Quote:
Original post by spraff
Oh, and I'm using VS 2008, not VS 6, sorry.
Phew [smile]

Share this post


Link to post
Share on other sites
0xfefefefe is a marker for deleted memory in debug mode. This means your object was deleted out from under you, or somehow overwritten and then explicitly freed.

Do you have any threading? That could easily cause the former, and timing issues might lead to sprintf being just faster enough to miss the crash cause. Put logging in your destructor and the top of this member function to test for this.

It's unlikely that sprintf overwrote the local instance of the object and then explicitly freed it, however, if value isn't a type that is explicitly okay to use with %d in printf-like functions, you will get bizarre crashes that I suppose might end up looking like this.

Share this post


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

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

GameDev.net is your game development community. Create an account for your GameDev Portfolio and participate in the largest developer community in the games industry.

Sign me up!