Messages in this thread | | | Date | Mon, 28 Jun 1999 10:57:37 -0600 | From | Rob Riggs <> | Subject | Oops in sock_select (again) |
| |
2.0.3[67] kernels can oops in sock_select() when running a threaded application.
This bug has be known and reproducible for almost half a year now. See the following post from January 13:
http://www.tux.org/hypermail/linux-kernel/1999week03/1133.html
This may be the longest time a known, reproducible oops has remained in the Linux kernel!
There is what appears to be a related problem in 2.2 kernels, which result in the threads being stuck in skb_recv_datagram.
I'll also include a bit of C code, since no one was interested in my Python code used to trigger these problems. I've dug into the kernel code and have gotten nowhere. This has been reproduced on many different machines, SMP and UP. This oops still occurs in 2.0.37. It can be triggered with threaded calls to gethostbyname_r().
I do find it interesting that the same code that produces oopses in the 2.0 series results in hung processes under 2.2.
For reference, my original post can be found here:
http://www.tux.org/hypermail/linux-kernel/1999week26/0796.html
One hint is that after some of the 2.0 oopses, the message "VFS: Close: file count is 0" is found in the syslog.
I am beginning to believe that there is some interaction with the loading of the NSS shared libraries that is triggering these problems (at least under 2.2). Here's why:
$ uname -a Linux diamond.pangalactic.org 2.2.9 #11 SMP Wed Jun 9 10:27:19 MDT 1999 i686 unknown $ ./thrtest # Exited successfully -- oddly enough. Very rare. $ ./thrtest # Had to ^C to exit. Hung in skb_recv_datagram $ ./thrtest ./thrtest: error in loading shared libraries /lib/libresolv.so.2: undefined symbol: __res_close ./thrtest ./thrtest: error in loading shared libraries /lib/libresolv.so.2: undefined symbol: res_querydomain
Of course there is absolutely nothing wrong with libresolv.so, and similar errors will occur for all of the libnss_xxx.so libraries. And, in fact, the program continues to run.
Re-arranging the resolver order in nsswitch.conf doesn't appear to have any impact on the problem, unless the host to be resolved is in /etc/hosts and 'hosts' appears before 'dns' in the /etc/nsswitch.conf 'hosts:' line.
-- Rob Riggs Technical Staff Tummy.com, Ltd. http://www.tummy.com/[unhandled content-type:application/x-gzip]
| |