Buffer overflow founded when migrate a c application from AIX to Solaris
I migrated a c application using the cc compiler from AIX version 5 to Solaris 10.
First, I compiled my application with cc compiler using Solaris 10. I did not use special compilation options and compiled without error.
Then, I run the application and found the first buffer overflow, then corrected the application y run it again. I founded more buffer overflow in different places of the application.
A buffer overflow occurs when data written to a buffer, due to insufficient bounds checking, corrupts data values in memory addresses adjacent to the allocated buffer. Most commonly this occurs when copying strings of characters from one buffer to another.
I understand that the right thing would be to detect case by case, each of these errors and make the correction in the corresponding variable, however, the time is important.
Are there any option to compile or a pragma directive or a kernel parameter or something that makes the c application using Solaris 10 behave the same way as in cc compiler for AIX ?
Waiting for your help!
Re: Buffer overflow founded when migrate a c application from AIX to Solaris
Quote:
Originally Posted by
garmon
Are there any option to compile or a pragma directive or a kernel parameter or something that makes the c application using Solaris 10 behave the same way as in cc compiler for AIX ?
Waiting for your help!
No.
Your program has a bug, so fix your program. Just because you don't see a problem when you run your program under another OS doesn't mean that the bug doesn't exist there also.
I see this asked so many times here about 'C' or C++ applications running with known bugs, but run "OK" on one OS and fail on another. There is no magic in trying to get the misbehaving program to work. If there is any magic, that magic is called "debugging" and fixing the errors.
Secondly, a memory overwrite or buffer overflow doesn't automatically mean the program will stop working. Unlike other computer languages, 'C' or C++ doesn't automatically stop with error messages when you have a memory overwrite. The program may continue to run as if nothing is wrong, crash right away, run on one computer and crash on another computer, etc.
Regards,
Paul McKenzie
Re: Buffer overflow founded when migrate a c application from AIX to Solaris
You might try to run it on a platform that does debug bounds checking. This should allow you to see each and every out of range operations instantly, so you can fix them, rather than having to investigate each problem.
Re: Buffer overflow founded when migrate a c application from AIX to Solaris
Quote:
Originally Posted by
garmon
Are there any option to compile or a pragma directive or a kernel parameter or something that makes the c application using Solaris 10 behave the same way as in cc compiler for AIX ?
You should be glad that the Solaris compiler causes the buffer overruns to be detected. It may be that it is adding boundary checks to array accesses and is detecting mysterious and indeterminate errors that may already be present in the AIX version.
Re: Buffer overflow founded when migrate a c application from AIX to Solaris
Quote:
Originally Posted by
garmon
Most commonly this occurs when copying strings of characters from one buffer to another.
Indeed, which is why in a C++ program (which I know this is not), you should always prefer std::string or another string class over raw char arrays.
In the meantime, is valgrind available for your platform? If so, it will be invaluable in ensuring you've caught all the problems.
Re: Buffer overflow founded when migrate a c application from AIX to Solaris
Paul.
I was reading every compiler option from AIX and Solaris compiler. I don´t find one that can solve my problem. The same story for pragma directives and kernel parameters. I didn´t find a magic alternative.
I am understanding that magic options don´t exist. And the only way is to fix the bugs, but it is an application of my client with 100,000 lines of code. My client don´t want to fix the application, because he is waiting to find a "magic" alternative to solve this problem and take to much time to fix it. Is there this magic option?
Thanks for your advice!
Re: Buffer overflow founded when migrate a c application from AIX to Solaris
Quote:
Originally Posted by garmon
I am understanding that magic options don´t exist. And the only way is to fix the bugs, but it is an application of my client with 100,000 lines of code. My client don´t want to fix the application, because he is waiting to find a "magic" alternative to solve this problem and take to much time to fix it. Is there this magic option?
Unfortunately, as you have acknowledged, there is no magic option. However, what you can do is to say, make use of a static analysis tool to spot these bugs, write a test for each of them, and then fix the bugs.
Re: Buffer overflow founded when migrate a c application from AIX to Solaris
Quote:
Originally Posted by
laserlight
Unfortunately, as you have acknowledged, there is no magic option. However, what you can do is to say, make use of a static analysis tool to spot these bugs, write a test for each of them, and then fix the bugs.
Laserlight.
Can your recomend me one static analysis tool?
Re: Buffer overflow founded when migrate a c application from AIX to Solaris
Well, I'm not sure about static analysis, but as I said before, valgrind is an indispensable dynamic analysis tool. It will run the program much more slowly than normal, but what it finds will allow you to pinpoint problems quickly and effectively.
Just as with compiler errors, remember that earlier errors can cause later ones, so always fix the first reported issue first.
Re: Buffer overflow founded when migrate a c application from AIX to Solaris
Quote:
Originally Posted by
garmon
Paul.
I was reading every compiler option from AIX and Solaris compiler. I don´t find one that can solve my problem. The same story for pragma directives and kernel parameters. I didn´t find a magic alternative.
Your program has a bug. It's that simple of an explanation.
Quote:
but it is an application of my client with 100,000 lines of code. My client don´t want to fix the application, because he is waiting to find a "magic" alternative to solve this problem and take to much time to fix it. Is there this magic option?
No there is no option.
When a C or C++ program has a bug that deals with memory overwrites or illegal memory accesses, an application can do anything. As I stated before, this is more or less, unique to the world of C and C++ programs -- a buggy C/C++ program can run differently on different days, different machines, different OSes, etc. Unlike languages such as Java, where you get notified with crash dumps when you do something wrong, C and C++ do not work this way. This is where I believe the disconnect is between you and your client is.
Your client has no idea that a bug exists because possibly they don't know about these situations. It's your job to explain it to him/her as best as possible. If your program were to show the wrong output, would your client like that? Would they want you to fix the program so that they get the correct output? A misbehaving C/C++ program that behaves "correctly" when run somewhere else is to be considered a bug just like showing wrong output would be, and needs to be fixed just like any other error (recreating the error, debugging, making source code changes to fix the error, testing, delivering new version to client).
As to your experience, have you not heard of applications that work correctly on the programmer's machine, but as soon as it is delivered to the public, the programmer(s) start to get bug reports? How is that possible when the program worked correctly at the shop? It's not just OS differences that can reveal bugs -- just running on another machine can cause a bug to happen that doesn't happen on another machine.
Which means this -- the other version you say is running "fine" is not running fine -- it is also faulty. Hopefully whatever fixes you made for the Solaris version, you're making those same fixes for the version that is working.
Regards,
Paul McKenzie