kern/37436: [hang] accept dead loop when out of file descriptors

Kip Macy kip.macy at gmail.com
Tue Nov 20 20:29:14 PST 2007


If you can send me a test case to reproduce I'll track down where the
error is coming from.

 -Kip


On Nov 20, 2007 8:13 PM, Jin Guojun <jin at george.lbl.gov> wrote:
>
> Kip Macy wrote:
>
> >On Nov 16, 2007 5:34 PM, Jin Guojun <jin at george.lbl.gov> wrote:
> >
> >
> >>kmacy at FreeBSD.org wrote:
> >>
> >>
> >>
> >>>Synopsis: [hang] accept dead loop when out of file descriptors
> >>>
> >>>State-Changed-From-To: open->feedback
> >>>State-Changed-By: kmacy
> >>>State-Changed-When: Sat Nov 17 01:19:37 UTC 2007
> >>>State-Changed-Why:
> >>>
> >>>Is this still an issue?
> >>>
> >>>http://www.freebsd.org/cgi/query-pr.cgi?pr=37436
> >>>
> >>>
> >>>
> >>>
> >>I will check into it in a week.
> >>
> >>
> >
> >By "still", I mean RELENG_6 or better yet RELENG_7.
> >
> > -Kip
> >
> >
> Another slightly odd thing is discovered during repeat this test.
> The maximum number of threads (pthread_create via libthr) can be created
> is 111.
> Therefore, there is no way to reproduce this problem due to
> pthread_create problem.
>
> The pthread_create() fails due to Error<35> Resource temporarily
> unavailable. However,
> memory allocation is still functioning. I have tested on a 256MB laptop
> and a 1GB desktop,
> both had the same problem for pthread creation -- maximum 111 threads
> can be created.
> Below is my resource limits and I do not believe that is the problem:
>
> /home/users/libthr: limit
> cputime      unlimited
> filesize     unlimited
> datasize     1048028 kbytes
> stacksize    65536 kbytes
> coredumpsize unlimited
> memoryuse    unlimited
> vmemoryuse   unlimited
> descriptors  11095
> memorylocked unlimited
> maxproc      5547
> sbsize       unlimited
>
> It looks like 6.2-R and RELENG_6/7 kernel has some restriction on number
> of threads to handle,
> because all libthr, libpthread and libc_r all behave the same.
> Is this true?
>
> So, that only test can be done is to set descriptors limit to 117 on the
> server to test 111
> connections from a client. Such test is Ok.
> If the descriptors limit is set to 116, the accept will return error
> without hanging.
> But I do not know if this will be true when the number of descriptors
> used is larger.
>
> I tried to run the same command multiple times on the same client, it
> does not help much.
> I will look this issue further.
>
> -Jin
>


More information about the freebsd-bugs mailing list