EXC_BAD_ACCESS and seg faults with BSD Sockets code

Question

Hi,
I've been having some problems with sockets programming on a new MacBook that I've decided to do some programming on.
So, I wrote a pretty simple program to test if the sockets are working properly, and it's only partially working.
I've been compiling via gcc on the command line, but then I tried Xcode to see if that made any difference, and it didn't.
Also, this program works flawlessly on FreeBSD 6.2. The Apple Developer website says that BSD sockets should work perfectly.
Here's the code: http://www.wraithnj.com/matt/Programming/C/scrabble/server/server.c
I've been testing this code with netcat, telnet, and this too: http://www.wraithnj.com/matt/Programming/C/scrabble/client/client.c
Xcode and GDB reveals that it fails line 57. Or at least that's where the break point is set. Appearantly it doesn't like the FD_SET() macro... Perhaps I'm just being an idiot and don't know how to use Xcode.
So, this is what it looks like when it fails (after connecting with a client):
matt@mdwosx1:~/Programming/C/scrabble/server# ./server2
Connection from: 127.0.0.1 Socket: 4
Then the program doesn't crash. It sends the "playerid." The client receives the 1 sent.
Then if I try to send the server any information (typing in stuff from the client) the server doesn't show that it has received the information. Then if I send 'q' from the client. It has a segmentation fault. If I just do Ctrl+C with the client, it receives another segmentation fault. I don't understand what memory it's trying to write to that it can't. I'm assuming that it's having trouble writing to the fd_set master because that's where gdb leads me, but that's confusing because that works fine on FreeBSD.
If I connect two clients, the second the second client connects it runs into an infinite loop.
It repeats this:
DATA From: 2.0.0.0 Socket: 3 Data:
DATA From: 2.0.0.0 Socket: 3 Data:
DATA From: 2.0.0.0 Socket: 3 Data:
DATA From: 2.0.0.0 Socket: 3 Data:
DATA From: 2.0.0.0 Socket: 3 Data:
DATA From: 2.0.0.0 Socket: 3 Data:
Until you quit from both clients, where it drops a segmentation fault.
The GDB in Xcode says EXCBADACCESS.
I honestly have no clue what I'm doing wrong. I added a whole bunch of header files (in case Mac OS X depends upon something else). I recompiled it every which way. I reconfigured Xcode every which way.
Could anybody help me or shed some light on what I'm doing wrong?
-WraithM

Answer 1

I did have an extra byte on each of my character arrays. The fix was adding two extra bytes. For example, with my playerid in the client, originally (in the program before the fix that worked perfectly on FreeBSD) I had playerid[1] in the declaration. Aka, two bytes. I store the first byte in the first element, then I stored the null in the second element. Under OS X, when I declared 2 elements, the recv function was overflowing into the next variable (so, it was taking up three elements, somehow). So, then I redeclared my playerid array with three elements, and it worked out. So, there's a specific difference between OS X and FreeBSD. I also did specifically take in one less byte than size of my array and null terminated by myself. For example,
numbytes = recv(sock, playerid, 1, 0);
playerid[numbytes] = '\0';
Note that I originally had it declared as 2 bytes long. So, I read 1 byte in, then I null terminate the second byte. numbytes should be 1 if I'm reading 1 byte. That's what recv sends as the return value. Therefore playerid[1] = '\0';
I did EXACTLY what you suggested even before I fixed it. Okay, so your suggestion of what the problem is isn't a fair assessment of the situation. There's a specific difference between OS X and FreeBSD. Remember, this code worked perfectly on FreeBSD before and after the changes. So, when I null terminate, it's taking up two bytes somehow. Also, it's not like the null termination is being put in the third element of the array because I tried doing:
playerid[numbytes - 1] = '\0'; It over wrote the first element.
I don't need to review C strings. I'm getting lucky because I guessed how to fix the situation based upon the perceived differences between OS X and FreeBSD, not because I'm making random changes. I need somebody to explain what OS X is doing that FreeBSD isn't doing (or visa versa).
Also, you're wrong:
Your code only works because you make sure that atoi() is less than 2 and you've make that playerfd array have [two elements].
I originally declared it with TWO elements, and it didn't work because I didn't offset the index of playerfd. Then I declared it with three elements, and it worked. That's because I changed the size of playerfd, but now I fixed the problem (and now I am back to having two elements with a new solution), but that doesn't explain why this worked on FreeBSD and not OS X.
Addmittedly, I didn't think about this before, but here's the real way I should have done this.
if(atoi(&playerid) < 2)
      playerfd[atoi(&playerid) - 1] = newsock;
Because the playerid is either 1 or 2, it'd put it in either the second or third element, not the first or second element. So, I just offset the atoi, and now I can do that with a two element declaration. It was a silly mistake on my part.
However, that doesn't explain what's going on in the client where the null-termination is going over into the next array (unless I have 3 elements instead of something that should have 2 elements (the number then the null termination)). Nor does that explain why this code worked on FreeBSD. I can understand why the server worked in FreeBSD. There could have been nothing important after the playerfd array in the server (which doesn't really make sense, because the compilers should have the same variables next to eachother, but conceivably that's how it'd work). However, on the client, if I tried to do printf of playerid with a strange offset like in the server, then I'd get this:
0x[0031]00 (the brackets defining where the playerid array with 2 elements is)
It wouldn't print anything because it'd hit the null right off the bat.
So, what must be happening is this:
0x[3100]00
The 00 after the playerid bracket is where the overflow is occurring. Normally, the socket file descriptor is there, and that gets overwritten with 0. In FreeBSD, it worked fine.
So, when I define the array to be 3 elements long, it must be working like this:
0x[310000]04 (04 being the socket file descriptor that occurs after the playerid array)
There are two nulls... Something is strange about this. This is what I don't understand as not working in OS X and working in FreeBSD.
Could anybody explain this?
P.S. I don't like initializing all of my data, nor error checking during designing of a basic program. I put them in afterwards because I find them to be aesthetically displeasing, and it makes it more difficult to find stuff. I know it's stupid, but that's how I work. I put in error checking when I'm debugging specific sections, and then put it in everywhere after is all worked out. My coding style is not the problem. Admittedly, I was stupid with the server, but I honestly don't understand the client. The nature of the server and client are different. In the server, I'm using an integer array, and in the client I'm using a character array.
Message was edited by: WraithM