lkml.org 
[lkml]   [1999]   [Jun]   [28]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectOops 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]
\
 
 \ /
  Last update: 2005-03-22 13:52    [W:0.039 / U:0.212 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site