Jump to content

  • Log In with Google      Sign In   
  • Create Account

Awesome job so far everyone! Please give us your feedback on how our article efforts are going. We still need more finished articles for our May contest theme: Remake the Classics

A peculiar problem ...


Old topic!
Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.

  • You cannot reply to this topic
8 replies to this topic

#1 Dragonion   Members   -  Reputation: 120

Like
0Likes
Like

Posted 14 August 2011 - 03:21 PM

Hi

I have just encountered a rather non-trivial problem. First, look at this code:

char buffer[24];
sprintf_s(buffer,24,"Year=%f",2011);
This works beautifully! The string is copied nicely into the buffer as it is supposed to, and afterwards everything else continues smoothly.

Now, look at this code:

char buffer[24];
sprintf_s(buffer,24,"Year=%f",2011);
This is nothing less than a pure catastrophe! As soon as it is executed the program crashes, Windows pops up a message-box telling me that the program needs to close, and I am pretty sure that if it wasn't for Windows' Security Center it would erase my hard-drive as well.

The thing is that the first lines of code are executed in the main thread (the program) while the second ones are executed in a DLL procedure called by the main thread. Under different circumstances I would agree that two lines of code is not much to go on, but the essence of the problem can really be boiled down to why sprintf_s is causing the program to crash when invoked in a DLL procedure? (If you want to try it yourself first create a DLL file and export a function using sprintf_s. Then simply call the function from a test app to see the crash).

I have no idea what's causing this behavior so I am crossing my fingers one of you will be able to enlighten me.

PS1: I have also tried using std::stringstream/strings to solve the problem (converting a floating-point value to ASCII), but this solution crashed as well.
PS2: Floating-point support is loaded in both the program and in the DLL.

#2 Brother Bob   Moderators   -  Reputation: 4635

Like
0Likes
Like

Posted 14 August 2011 - 03:58 PM

The only thing I can see that is wrong with the code you show is the format specifier and the value being passed. You pass an integer, but the format specifier is a floating point value. That, in itself, should just produce garbage output (it's undefined in theory, but in practice that is what you're likely to get), but the problem is that it's a double precision floating point value, and your integer is likely not the same size. Most likely you're passing a 4-byte integer and sprintf_s reads an 8-byte floating point value from where the values are passed. You need to ensure that the value passed is really a double precision floating point value.

#3 Dragonion   Members   -  Reputation: 120

Like
0Likes
Like

Posted 14 August 2011 - 04:08 PM

The only thing I can see that is wrong with the code you show is the format specifier and the value being passed. You pass an integer, but the format specifier is a floating point value. That, in itself, should just produce garbage output (it's undefined in theory, but in practice that is what you're likely to get), but the problem is that it's a double precision floating point value, and your integer is likely not the same size. Most likely you're passing a 4-byte integer and sprintf_s reads an 8-byte floating point value from where the values are passed. You need to ensure that the value passed is really a double precision floating point value.

I see you point, but 1) the constant is correctly converted to a double value in the program (in which there are no problems executing these lines), and 2) even if I omit the value and simply write
sprintf_s(buffer,24,"hello");
it still crashes :-/

#4 Chargh   Members   -  Reputation: 110

Like
0Likes
Like

Posted 14 August 2011 - 04:30 PM


The only thing I can see that is wrong with the code you show is the format specifier and the value being passed. You pass an integer, but the format specifier is a floating point value. That, in itself, should just produce garbage output (it's undefined in theory, but in practice that is what you're likely to get), but the problem is that it's a double precision floating point value, and your integer is likely not the same size. Most likely you're passing a 4-byte integer and sprintf_s reads an 8-byte floating point value from where the values are passed. You need to ensure that the value passed is really a double precision floating point value.

I see you point, but 1) the constant is correctly converted to a double value in the program (in which there are no problems executing these lines), and 2) even if I omit the value and simply write
sprintf_s(buffer,24,"hello");
it still crashes :-/


Did you change the line in both the exe and the dll?

EDIT: Do you know for sure it crashes at that exact line? What tools are you using? Try using a debugger, the normal 'this program stopped working' can mean a whole range of things.

#5 L. Spiro   Crossbones+   -  Reputation: 5155

Like
0Likes
Like

Posted 15 August 2011 - 01:40 AM

sprintf_s(buffer,24,"hello");

This can’t crash by itself if you are sure the buffer is 24 characters.
  • Ensure the DLL code is up-to-date. Rebuild-All. Make sure it is definitely the one being used by the host program.
  • Regardless of getting lucky the first time the code was called, either change %f to %u or change 2011 to 2011.0f. Having it work once is no justification for ever using %f with 2011.
  • Make sure that really is the source of the error. Because if the DLL is up-to-date and the buffer is 24 characters long, that is not the source of the error.

L. Spiro
It is amazing how often people try to be unique, and yet they are always trying to make others be like them. - L. Spiro 2011
I spent most of my life learning the courage it takes to go out and get what I want. Now that I have it, I am not sure exactly what it is that I want. - L. Spiro 2013
L. Spiro Engine: http://lspiroengine.com
L. Spiro Engine Forums: http://lspiroengine.com/forums

#6 Dragonion   Members   -  Reputation: 120

Like
0Likes
Like

Posted 15 August 2011 - 02:22 PM

Thanks for your feedback!

It turns out the crash occurred because I had forgotten to initialize a pointer in a constructor (which caused it to have some random value after afterwards). Oddly, this variable wasn't used anywhere near the place I call sprintf_s, but what the heck; if that's what it takes to make the boat float ;)

#7 Telastyn   Members   -  Reputation: 3329

Like
0Likes
Like

Posted 15 August 2011 - 02:27 PM

Thanks for your feedback!

It turns out the crash occurred because I had forgotten to initialize a pointer in a constructor (which caused it to have some random value after afterwards). Oddly, this variable wasn't used anywhere near the place I call sprintf_s, but what the heck; if that's what it takes to make the boat float ;)


...and this (among other reasons) is why we don't recommend C or C++ for beginners.

#8 Dragonion   Members   -  Reputation: 120

Like
0Likes
Like

Posted 15 August 2011 - 03:04 PM

...and this (among other reasons) is why we don't recommend C or C++ for beginners.

Hahaha! Yeah, 9 years of C/C++ apparently isn't enough to advance to the next level ;D

#9 mhagain   Members   -  Reputation: 3825

Like
0Likes
Like

Posted 15 August 2011 - 04:45 PM

Thanks for your feedback!

It turns out the crash occurred because I had forgotten to initialize a pointer in a constructor (which caused it to have some random value after afterwards). Oddly, this variable wasn't used anywhere near the place I call sprintf_s, but what the heck; if that's what it takes to make the boat float ;)


Yup, that's what stray pointers do. Always initializing everything is a good habit to get into.

Glad you found it.

It appears that the gentleman thought C++ was extremely difficult and he was overjoyed that the machine was absorbing it; he understood that good C++ is difficult but the best C++ is well-nigh unintelligible.





Old topic!
Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.



PARTNERS