atoi(), itoa() ... make system getting crash

Hi all,

We do not know why our system get crash after 2-3 years run well by a lot of issue come from atoi(), itoa(), atof(), atol(), strtod(), strtol(), itoa(), etc APIs. If we replace them by sscanf and sprintf, the system does not getting crash. We do not know what is the clue of this. We are appreciate to receive reply from you.

Thanks,

Nguyen

It could be the buffer overrun that crashing your system, since you are using deprecated APIs.

It may be that the problem still exists with sprintf too, but the error is not 'fatal'. The errors associated with these sort of functions is usually the data being sent to them. Array overruns, non-terminated strings, double & int pointers being cast to each other and dereferenced can all cause weird and wonderful errors.

If you can, consider using the C++ streaming classes as they are typesafe and can reduce the chances of silly errors being introduced.

Code:

---

// itoa equivalent.
int value;
ostringstream oss;
oss << value;

string text_value(oss.str()); // text_value contains the string representation of value

---

Code:

---

// atoi equivalent.
int value;

istringstream iss("1234");
iss >>  value;

---

For atof replace the int by a float.

Code:

---

// sprintf equivalent
int i_value = 0;
double d_value = 1.2;

ostringstream oss;
oss << "The integer value is " << i_value << "\nThe double value is " << d_value << "\n";
 
string text(oss.str());

---

Quote:

---

Originally Posted by PeterNguyen

Hi all,

We do not know why our system get crash after 2-3 years run well by a lot of issue come from atoi(), itoa(), atof(), atol(), strtod(), strtol(), itoa(), etc APIs. If we replace them by sscanf and sprintf, the system does not getting crash. We do not know what is the clue of this. We are appreciate to receive reply from you.

---

Your program has bugs with memory overwrites. I don't know what else to tell you, since we do not have any of your code. Those functions are standard 'C' functions, and I highly doubt there is anything wrong with them. What must be wrong is the way you're using them and the data you're sending to them.

Also, just because you replaced one set of routines with another doesn't mean the bug is fixed. You could still have a bug in your program, and all you did was move the bug to another area of the program. You must know exactly why the bug happens and fix it, and not try random things.

Regards,

Paul McKenzie

Thanks JohnW@Wessex and Paul McKenzie much!

One example is atof function in our code:

virtual void SetDataText(CString &strText, int intAdditionInfo) { m_fdata = atof((LPCSTR)strText);}

And many such lines of code in our system (atoi(), strtod(), itoa(), itoa(), etc APIs issue), we fixed by replacing atof with sscanf:

virtual void SetDataText(CString &strText, int intAdditionInfo) { sscanf((LPCSTR)strText, "%f", &m_fdata);}

Hence, our system run well, it doesn't get "Runtime Error" till now. But I still confuse about that fixed since we haven't got out the root cause yet!

And could you suggest me the correct (safe) way of using these APIs to fix the bugs?

Thanks
Nguyen

It sounds like one of those difficult bugs where an error in one area of the code is causing corruption in an apparently unconnected area.

As Paul said, by changing the function calls you've just moved the problem to some place where it is causing less damage.

Quote:

---

Originally Posted by PeterNguyen

And many such lines of code in our system (atoi(), strtod(), itoa(), itoa(), etc APIs issue), we fixed by replacing atof with sscanf:

---

I'm going to be honest with you -- replacing the functions with others is the worst thing you should have done to fix the problem.

I have a rule -- If there is a bug, never replace one set of functions with another until it is verified that the problem is with the functions that are to be replaced. As I stated previously, there is nothing wrong with atof(), atoi(), etc. It is the way you have been using them or the data you're sending to them, or a problem with some other part of the code that is causing these functions to fail.

It would have been better for you to leave the functions alone, let the bug occur, and fix the bug. Right now you are in a much worse position, as what you did was put the bug somewhere else, and you don't know where it is now. It is a good thing to know where and when a bug occurs, so that later it can be fixed. You should not have altered the code in any way until the bug was diagnosed and a fix was verified.

Regards,

Paul McKenzie

If you are running under Windows then you could use the line below, scattered around the code.

Code:

---

assert(CrtCheckMemory());

---

Running in debug mode, you may be able to home in on the section of code that is causing any corruption.

In the code snip posted I don't see any validation of the input string. how do you know that the CSTRING is filled with something? The fact that making changes to the code eliminates the problem might be a clue. I suggest reverting back to the original code and duplicating the problem. Then spend some time debugging the root cause so that you can figure out the correct way of solving the problem.

Thanks all for your idea!

I guess that the over stack might come from the using of CString and LPCSTR: the convertion values between them.
So could I can come up with the solution as below?

old code:

virtual void SetDataText(CString &strText, int intAdditionInfo)
{
m_fdata = atof((LPCSTR)strText);
}

new code:

virtual void SetDataText(CString &strText, int intAdditionInfo)

{
LPCSTR szTemp =(LPCSTR)(LPCTSTR) strText;

m_fdata = atof(szTemp);
}

Thanks,

Nguyen

Quote:

---

Originally Posted by PeterNguyen

I guess that the over stack might come from the using of CString and LPCSTR: the convertion values between them.

---

I very much doubt it. Be aware that when a problem like this occurs it is entirely possible that a completely unrelated part of the code is corrupting some part of the code to do with atoi atof etc. causing them to fail when you use them next.

Have you tried sprinkling some assert(CrtCheckMemory()); around yet?

I can suggest a simple thing: try to printf() your strText by byte and watch if there is a problematic content inside.

[I very much doubt it]

Did you mean that the bug is not come from the line: (LPCSTR)strText and it come from some where part code?

Actually I'm not familiar with assert(CrtCheckMemory()); Do you have any link to show how to use it?

Thanks,
Nguyen

Quote:

---

Originally Posted by PeterNguyen

Did you mean that the bug is not come from the line: (LPCSTR)strText and it come from some where part code?

---

Unless you are not using the API of CString and directly changing the internals of the object using pointers. Otherwise LPCSTR is not expected to fail.

Quote:

---

Actually I'm not familiar with assert(CrtCheckMemory()); Do you have any link to show how to use it?

---

Add the line at key points in the code and run in debug mode.
When code is compiled in this mode, markers are placed around every data object in memory. CrtCheckMemory() will check the integrity of these markers and return FALSE if anyone of them has been corrupted. The assert stops execution of application.
When you find the point at which the corruption occurs, you can move the memory check lines to more specific sections of the code. Hopefully you will eventually track it down to a single function call. At that point you will leap from your chair shouting "Of course! It's obvious why it failed!"

Quote:

---

Originally Posted by ckweius

It could be the buffer overrun that crashing your system, since you are using deprecated APIs.

---

I do not know why you said that these APIs are deprecated?

Thanks,
Nguyen

Quote:

---

Originally Posted by PeterNguyen

I do not know why you said that these APIs are deprecated?

Thanks,
Nguyen

---

You could try a google search on the word deprecated.
http://en.wikipedia.org/wiki/Deprecation

My earlier suggestion was similar to something that John mentioned. There could be something wrong with the CString object itself or the memory. Creating your own temporary inside that function isn't going to change what the compiler is already doing for you during compilation. Sometimes the compiler will create temporary variables as a result of some operation or cast you have written. Creating intermediate variables may not help too much unless it is for debugging purposes. Sometimes having the intermediates is useful when stepping so that you can see that a conversion is actually working.

By the way, when you say that your software is crashing how is it crashing? Are you able to get anything useful out of the call stack? Is it crashing in debug mode or only release mode? I haven't seen you post any details about what you have done to try to debug the problem (other than changing the code, recompiling, and re-running). What tools do you have available for debugging?

Quote:

---

Originally Posted by kempofighter

You could try a google search on the word deprecated.
http://en.wikipedia.org/wiki/Deprecation


By the way, when you say that your software is crashing how is it crashing? Are you able to get anything useful out of the call stack? Is it crashing in debug mode or only release mode? I haven't seen you post any details about what you have done to try to debug the problem (other than changing the code, recompiling, and re-running). What tools do you have available for debugging?

---

Thanks you much. I have just go through the link you suggested, but it likely no proof that these APIs are deprecated. You mean that we should not use these APIs since they are deprecated? Instead that we should use some safer, more secure functions??? My system based on VSC++6.0 and running on Windows XP or Windows 2000. It suddenly get crashes by "Runtime Error". Yes, it happened on release mode!



Thanks,

Nguyen

Quote:

---

Originally Posted by PeterNguyen

I have just go through the link you suggested, but it likely no proof that these APIs are deprecated. You mean that we should not use these APIs since they are deprecated?

---

Those functions from the C standard library are not deprecated. However, itoa() is non-standard, and may cause buffer overflow if you do not provide it with a destination string of sufficient length, while atoi(), atof() and atol() do not provide a way for you to check for errors in conversion.

Quote:

---

Originally Posted by PeterNguyen

I do not know why you said that these APIs are deprecated?

---

Most CRT functions have corresponding more secure version with the '_s' suffix. To put it simple, deprecated functions will simply crash the application when errors (such as buffer overrun) occured.

However, newer CRT functions are not meant to fix security issues, but to catch and divert control to most appropriate error handler (rather than crashing).

Quote:

---

Originally Posted by ckweius

Most CRT functions have corresponding more secure version with the '_s' suffix. To put it simple, deprecated functions will simply crash the application when errors (such as buffer overrun) occured.

---

However, those functions are non-standard, at least for now. As such, the "deprecation" of the standard library functions is not technically deprecation, but discouragement by a certain family of compilers via compiler warnings which can be disabled.

I got your idea and suggestions. Your support was highly appreciated. Thanks all!

One more thing I'm confusing that is: These APIs e.g atoi, atof, strtod,.. etc only can covert ASCII string to number? If we use convert from Unicode to number, what is the problem?

Thanks,
Nguyen

Quote:

---

Originally Posted by PeterNguyen

One more thing I'm confusing that is: These APIs e.g atoi, atof, strtod,.. etc only can covert ASCII string to number? If we use convert from Unicode to number, what is the problem?

---

To convert Unicode string to integer, use _wtoi().

Quote:

---

Originally Posted by ckweius

Most CRT functions have corresponding more secure version with the '_s' suffix. To put it simple, deprecated functions will simply crash the application when errors (such as buffer overrun) occured.

However, newer CRT functions are not meant to fix security issues, but to catch and divert control to most appropriate error handler (rather than crashing).

---

'_s' suffix may be used only on .NET, but out system is based on VSC++6? Is there any more secure version can work on VSC++ to catch and divert control to most appropriate error handler (rather than crashing)

Thanks,
Nguyen

Quote:

---

Originally Posted by PeterNguyen

'_s' suffix may be used only on .NET, but out system is based on VSC++6? Is there any more secure version can work on VSC++ to catch and divert control to most appropriate error handler (rather than crashing)

---

You'll have to write your own routines if you're (still) using VC 6.0.

Regards,

Paul McKenzie

Quote:

---

Originally Posted by JohnW@Wessex

It may be that the problem still exists with sprintf too, but the error is not 'fatal'. The errors associated with these sort of functions is usually the data being sent to them. Array overruns, non-terminated strings, double & int pointers being cast to each other and dereferenced can all cause weird and wonderful errors.

If you can, consider using the C++ streaming classes as they are typesafe and can reduce the chances of silly errors being introduced.

Code:

---

// itoa equivalent.
int value;
ostringstream oss;
oss << value;

string text_value(oss.str()); // text_value contains the string representation of value

---

Code:

---

// atoi equivalent.
int value;

istringstream iss("1234");
iss >>  value;

---

For atof replace the int by a float.

Code:

---

// sprintf equivalent
int i_value = 0;
double d_value = 1.2;

ostringstream oss;
oss << "The integer value is " << i_value << "\nThe double value is " << d_value << "\n";
 
string text(oss.str());

---

---

Hi all,

The link below show that STL std::string class causes crashes and memory corruption on multi-processor machines
http://support.microsoft.com/kb/813810

Could you have any suggestions?

Thanks,
Nguyen

Quote:

---

Originally Posted by PeterNguyen

The link below show that STL std::string class causes crashes and memory corruption on multi-processor machines
http://support.microsoft.com/kb/813810

Could you have any suggestions?

---

The suggestions are given in the very article that you linked to:

• Upgrade to a newer version of MSVC, or,
• Use a replacement standard library implementation.