From Bugzilla Helper: User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1; .NET CLR 2.0.50727) Description of problem: select() doesn't seem to work properly multicast. mcasttest.cpp illustrates the problem. cleansockets.h allows the code to be compiled on windows; it's just standard headers on linux. Output: setting up recieving select()ing returned 0 FD_ISSET not set got 1 This shows that select() is not detecting that the socket has recieved data, but it obviously has recieved data because recvfrom() returns packets. Strangely the code works when compiled on windows and run under WINE! >wine mcasttest.exe returns: setting up recieving select()ing returned 1 FD_ISSET got 1 This would imply the WINE people know about this problem and worked around it. I've played with this for a while removing a few sockopts here and there, but for naught. Version-Release number of selected component (if applicable): kernel-2.6.17-1.2187_FC5 kernel-2.6.17-1.2174_FC5 How reproducible: Always Steps to Reproduce: 1) compile: gcc -o mcasttest -lstdc++ mcasttest.cpp 2) send data: ./mcasttest s 3) recieve (on another shell): ./mcasttest Actual Results: setting up recieving select()ing returned 0 FD_ISSET not set got 1 Expected Results: setting up recieving select()ing returned 1 FD_ISSET got 1 Additional info: I've done an automatic update a few days ago. I'm running: [root@ares mcasttest]# rpm -q kernel kernel-2.6.17-1.2174_FC5 kernel-2.6.17-1.2187_FC5 ... Fedora Core release 5 (Bordeaux) i686
Created attachment 138039 [details] main code - illustrates the bug Sorry for forgetting to attach this right away!
Created attachment 138040 [details] Just standard headers on Linux, does windows compatiblity
A new kernel update has been released (Version: 2.6.18-1.2200.fc5) based upon a new upstream kernel release. Please retest against this new kernel, as a large number of patches go into each upstream release, possibly including changes that may address this problem. This bug has been placed in NEEDINFO state. Due to the large volume of inactive bugs in bugzilla, if this bug is still in this state in two weeks time, it will be closed. Should this bug still be relevant after this period, the reporter can reopen the bug at any time. Any other users on the Cc: list of this bug can request that the bug be reopened by adding a comment to the bug. In the last few updates, some users upgrading from FC4->FC5 have reported that installing a kernel update has left their systems unbootable. If you have been affected by this problem please check you only have one version of device-mapper & lvm2 installed. See bug 207474 for further details. If this bug is a problem preventing you from installing the release this version is filed against, please see bug 169613. If this bug has been fixed, but you are now experiencing a different problem, please file a separate bug for the new problem. Thank you.
Nope, it's still broken. I recompiled it and it does the same thing. select() returns nothing even thought the socket has data.
Your application is buggy. The first select argument should be "socketId + 1". Make that change and it will work properly, I just verified that here. If you copied the select() call from the Linux man page, you should note that the example given in the manpage is select()'ing on file descriptor "0", standard input, and therefore the first argument to select should be "0 + 1". Finally, you didn't provide the cleansockets.h header file, so I had to spend the time to put one together. Providing self-contained test cases makes your problem get looked at faster, just a note for the future.
Ok, my bad!!! I should have read the MAN page. I thought it was the number of sockets. On windows it's ignored. Theoretically select() can always calculate that parameter from the others, so debatebly it's a useless parameter. Maybe there's some speed benefit. Anyway thanks. Sorry. I hope my company will give you money. We've bought Red Hat licenses in the past and the customer(ING bank) we're doing this for may also give you something. Just for the record that header file "cleansockets.h" was attached in the 2nd comment. Sorry I didn't attach it immediately.
The first argument to select() provides two things: 1) An optimization, which you noticed, which reduces the amount of the fd bitmaps which the select() implementation has to scan. 2) An upgrade path for increasing the size of fd_set transparently. The kernel doesn't actually care how big these bitmaps are, all it would see is a larger first argument if "fd_set" were made larger in userspace and the application made use of that larger area.