[lkml]   [1999]   [Jun]   [28]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    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:

    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:

    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 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/ undefined symbol: __res_close
    ./thrtest: error in loading shared libraries
    /lib/ undefined symbol: res_querydomain

    Of course there is absolutely nothing wrong with,
    and similar errors will occur for all of the
    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, Ltd.[unhandled content-type:application/x-gzip]
     \ /
      Last update: 2005-03-22 13:52    [W:0.034 / U:34.536 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site