Sign in to follow this  

sprintf_s causes a crash

This topic is 3294 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
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.
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

This topic is 3294 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.

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

Sign in to follow this