CODEWITHSUNDEEP
clinuxsockets
trenki
trenki

Reputation: 7363

Linux server socket - Bad file descriptor

I have a problem with a server socket under Linux. For some reason unknown to me the server socket vanishes and I get a Bad file descriptor error in the select call that waits for an incomming connection. This problem always occurs when I close an unrelated socket connection in a different thread. This happens on an embedded Linux with 2.6.36 Kernel.

Does anyone know why this would happen? Is it normal that a server socket can simply vanish resulting in Bad file descriptor?

edit: The other socket code implements a VNC Server and runs in a completely different thread. The only thing special in that other code is the use of setjmp/longjmp but that should not be a problem.

The code that create the server socket is the following:

int server_socket = socket(PF_INET, SOCK_STREAM, IPPROTO_TCP);

struct sockaddr_in saddr;
memset(&saddr, 0, sizeof(saddr));
saddr.sin_family = AF_INET;
saddr.sin_addr.s_addr = htonl(INADDR_ANY);
saddr.sin_port = htons(1234);

const int optionval = 1;
setsockopt(server_socket, SOL_SOCKET, SO_REUSEADDR, &optionval, sizeof(optionval));

if (bind(server_socket, (struct sockaddr *) &saddr, sizeof(saddr)) < 0) {
    perror("bind");
    return 0;
}

if (listen(server_socket, 1) < 0) {
    perror("listen");
    return 0;
}

I wait for an incomming connection using the code below:

static int WaitForConnection(int server_socket, struct timeval *timeout)
{
    fd_set read_fds;

    FD_ZERO(&read_fds);
    int max_sd = server_socket;
    FD_SET(server_socket, &read_fds);

    // This select will result in 'EBADFD' in the error case.
    // Even though the server socket was not closed with 'close'.
    int res = select(max_sd + 1, &read_fds, NULL, NULL, timeout);
    if (res > 0) {
        struct sockaddr_in caddr;
        socklen_t clen = sizeof(caddr);
        return accept(server_socket, (struct sockaddr *) &caddr, &clen);
    }

    return -1;
}

edit: When the problem case happens i currently simply restart the server but I don't understand why the server socket id should suddenly become an invalid file descriptor:

int error = 0;
socklen_t len = sizeof (error);
int retval = getsockopt (server_socket, SOL_SOCKET, SO_ERROR, &error, &len );
if (retval < 0) {
    close(server_socket);
    goto server_start;
}

Upvotes: 9

Views: 37870

Answers (4)

Iman Mirzadeh
Iman Mirzadeh

Reputation: 13600

1- close your socket: 

close(sockfd);

2- clear your socket file descriptor from select set:

FD_CLR(sockfd,&master); //opposite of FD_SET

Upvotes: 4

GreenScape
GreenScape

Reputation: 7737

Sockets (file descriptors) usually suffer from the same management issues as raw pointers in C. Whenever you close a socket, do not forget to assign -1 to the variable that keeps the descriptor value:

close(socket);
socket = -1;

As you would do to C pointer

free(buffer);
buffer = NULL;

If you forget to do this yo can later close socket twice, as you would free() memory twice if it was a pointer.

The other issue might be related to the fact that people usually forget: file descriptors in UNIX environment start from 0. If somewhere in the code you have

struct FooData {
    int foo;
    int socket;
    ...
}

// Either
FooData my_data_1 = {0};
// Or
FooData my_data_2;
memset(&my_data_2, 0, sizeof(my_data_2));

In both cases my_data_1 and my_data_2 have a valid descriptor (socket) value. And later, some piece of code, responsible for freeing FooData structure may blindly close() this descriptor, that happens to be you server's listening socket (0).

Upvotes: 7

Rahul Bhansali
Rahul Bhansali

Reputation: 135

In Linux once you create a connection and it get closed then you have to wait for some time before making new connection. As in Linux, socket doesn't release the port no. as soon as you close the socket.

OR

You reuse the socket, then bad file descriptor want come.

Upvotes: -3

Jens Gustedt
Jens Gustedt

Reputation: 78963

You don't distinguish the two error cases in your code, both can fail select or accept. My guess is that you just have a time out and that select returns 0.

  • print retval and errno in an else branch
  • investigate the return value of accept seperately
  • ensure that errno is reset to 0 before each of the system calls

Upvotes: 1

Related Questions