Programming

Hello everybody,
I've been working on a program on my Linux box, after finished the code, i compile it with gcc -Wall option, so i can see what's wrong or unused.

The Walll output shows nothing, so there are no loose ends on the program.
I run the program on my system, and it works PERFECTLY.

My problem is when i copy the source code of the program and compile it on other operating systems (Also Linux, but live versions). It compiles without any warnings from -Wall, but when i run the program, i get segmentation fault.

Since most live versions doesn't have gdb, i figured out which functions were causing the segmentation fault myself, and it is confusing, because simple lines like:

Code:

strcpy(sockaddr.sa_data, argv[1]);

Are causing the segmentation violation.

I mean, the same code doesn't cause any segmentation fault or any other problem when running, but when i compile the code on other linux system (without warnings) and run it, it fails.

Does anybody know why this happens? Would it be a missing library, package, or something which my host has and the other one does not?

Thanks in advance.

Segmentation faults come from the outside of the program most times, in the sense that somebody enters a nodename with 400 characters. Instead of your expected size.

In a live environment, you have to program defensively. All input is poison. Period.
Something that comes in as argv[1] probably means means it was entered on the command line. Check lengths of string arguments. Check to see that numbers entered as a string are in fact numbers. And are in the range expected. Test input for acceptance, never test it to exclude, because you can never outwit the idiots running your code.

For example, test argv[1] for length. Make sure argc shows the right number of arguments. Absolutely, positively check ALL return codes from any runtime library.
getaddrinfo() will reject garbage node names for you, for example. So a lot of the burden of testing to find good input can be passed off to well-tested code.

Just because a program compiles, does not make it correct in any way. You should actively try to break your code with simulated bad input during unit testing, for example.
Before you test for correct behavior with good input.

If you have identical runtime libraries on your dev and live systems you can copy the core file from over there and may be able to debug it. If it was compiled stripped this may be of no help.

Hello, Jim. Thanks for your reply.

That's what i don't understand, because in this case there are no idiots giving wrong or different arguments than expected to the program. If i run, let's say: ./a.out eth0 in my host it runs perfectly, but in a live environment, and compiled on it, i run it with the same arguments, (./a.out eth0 in our example) and i expect to get the same result, but instead i get segmentation fault.

So, it's not a user mistake, i think it has to be with a libraries factor, a missing package, i don't know. I remember compiling the code on an earlier version of Linux and gcc returning warnings and not producing an executable file. I mean, if the code is working, correct and functionable on 2.6,2 it should be equally correct on 2.6.1

sockaddr might be null or has been overwritten and is pointing to some odd location.

Won't matter in this case:

Code:

strcpy(sockaddr.sa_data, argv[1]);

The sockaddr isn't an address - it's a structure, and the results of the strcpy() depend on long argv[1] is. It could segv, or not.

Now, the content of sa_data is almost certainly not expected to be in string format, though....

Won't matter indeed, I confused with sockaddr->sa_data