Comment #4 on issue 27446 by craig.schlenter: socket() sometimes returns zero despite stdin still being open http://code.google.com/p/chromium/issues/detail?id=27446
So there is a nice introduction to where all the socket stuff lives in the kernel here: http://www.skyfree.org/linux/kernel_network/socket.html and if you dig through that you'll find two interesting comments in the kernel: From net/socket.c (from sys_socket or SYSCALL_DEFINE3(socket...): /* It may be already another descriptor 8) Not kernel problem. */ and (from sock_alloc_fd or sock_map_fd depending on your kernel version): /* * Obtains the first available file descriptor and sets it up for use. * * These functions create file structures and maps them to fd space * of the current process. On success it returns file descriptor * and file struct implicitly stored in sock->file. * Note that another thread may close file descriptor before we return * from this function. We use the fact that now we do not refer * to socket after mapping. If one day we will need it, this * function will increment ref. count on file by 1. * * In any case returned fd MAY BE not valid! * This race condition is unavoidable * with shared fd spaces, we cannot solve it inside kernel, * but we take care of internal coherence yet. */ So that suggests to me that it is possible for the kernel to return a socket that corresponds to a fd that is already in use?? That would match what your strace is showing. Hmmm .... -- You received this message because you are listed in the owner or CC fields of this issue, or because you starred this issue. You may adjust your issue notification preferences at: http://code.google.com/hosting/settings -- Automated mail from issue updates at http://crbug.com/ Subscription options: http://groups.google.com/group/chromium-bugs
