YH wrote: > > If your application is crashing in select() with a SIGBUS/SIGSEGV error > > then somehow gave bad fd_set pointers to select(). This is not related > > to clients closing/aborting their connections. > > Spot on! This is exact the issue I've been troubled. If my server > program can detect the termination of a client program, it can close the > client's fd and remove it from fd_set. The problem is, my server program > could not catch SIGBUS/SIGSEGV, nor SIGPIPE or other signals from the > termination of the client program in my RH 9.0. I am not sure if it is > the RH 9.0 problem or the normal networking behavior. If your server is receiving SIGBUS/SIGSEGV signals, then your server code has a memory bug in it. Catching those signals _will not_ fix the bug. You do not need to catch those signals. Probably your server's bug is accessing memory after it is freed with free(), accessing through a NULL pointer, accessing an array beyond its bounds, or using fd_set incorrectly. You also should never receive SIGPIPE unless you are calling write(), or any of send/sendto/sendmsg() without the MSG_NOSIGNAL flag. You will not receive SIGPIPE from calling select() and/or read() - the SIGPIPE signal _only_ happens when you write something. > (1) Using signal function call to catch a signal from termination of a > client (it does not work currently in RH 9.0). If you are receiving SIGBUS/SIGSEGV signals, these are _not_ caused by termination of a client. They are caused by a memory bug in your server code, and catching the signals will not fix the bug. You might find the "gdb" or "valgrind" programs helpful for finding the bug in your server. Particularly "gdb", which will stop the program when those signals occur, and let you look at the code which is causing them. > (2) Find a networking system call, if there is, the client program can > inform the server it is off before terminating. I was imaging as there > is a pair system function of accept / connect for setting up a > connection, it might be another system function call to let client > program inform the server before terminating. But, I could not find from > Stevens's book. I could be missing something here, hope someone on this > list can give me a clue. Stevens book explains what happens when a client terminates. The server is notified automatically, and you will detect that through select() indicating that the socket is ready for reading; and read() from the socket will return zero, to indicate the end of all data from the client. -- Jamie - : send the line "unsubscribe linux-net" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
