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

[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.

Thanks,

Nguyen

[ckweius]

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

[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.

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

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

// atoi equivalent.
int value;

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

For atof replace the int by a float.

// 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());

[Paul McKenzie]

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

[PeterNguyen]

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

[JohnW@Wessex]

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.

[Paul McKenzie]

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

[JohnW@Wessex]

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

assert(CrtCheckMemory());

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

[kempofighter]

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.

[PeterNguyen]

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

[JohnW@Wessex]

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?

[AmadeusAD]

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

[PeterNguyen]

[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

[JohnW@Wessex]

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.

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!"

[PeterNguyen]

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