libc_r: threaded application could stuck in accept(2)
From: Ruslan Ermilov (ru_at_FreeBSD.org)
Date: 05/30/03
- Previous message: Alexandr Kovalenko: "jail && (ping && traceroute)"
- Next in thread: Enache Adrian: "Re: libc_r: threaded application could stuck in accept(2)"
- Reply: Enache Adrian: "Re: libc_r: threaded application could stuck in accept(2)"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]
Date: Fri, 30 May 2003 17:35:41 +0300 To: Daniel Eischen <deischen@FreeBSD.org>, hackers@FreeBSD.org
Hi!
We had a bug in our threaded application that would mistakenly close
the descriptor 0, and this triggers a bug in libc_r which I will try
to describe below.
The bug (in libc_r only, libpthread^Wlibkse is unaffected) causes a
threaded application to stuck in accept(2). libc_r makes every new
descriptor non-blocking, and uses poll(2) and thread context switching
to emulate a blocking behavior. The bug somehow causes the descriptor
to be left in a blocking mode.
Attached is the test case that demonstrates this bug (this is the
same on 4.8-STABLE and 5.1-BETA). The utility runs two threads:
the first thread prints the "alive" message every 3 seconds, and
the second thread emulates what our unfortunate application did,
i.e., open() a TCP socket, listen(), accept(), then close() it,
then mistakenly close() descriptor 0. (Closing the descriptor
0 causes the next socket() call to return 0.)
Some important notes: this bug is only applicable to descriptors
0 - 2 (stdio set), and might have something to do with the code
in uthread_fd.c. If you remove two lines that free the descriptor
0 in the attached test case, the bug won't manifest itself.
Attached also is the patch for the threaded close() function
that avoids the bug by disallowing the close() call on a
non-active descriptor.
The patch should be committed, but I'm now more interested in
what's going on inside libc_r that causes the descriptor 0 to
be left in the blocking mode. IOW, I wonder if the attached
patch is the real fix. ;)
Ah yes, when you'll run the application, it will report
which TCP port it listens to, you then connect to this port,
the application closes the connection, and on the next loop
the application gets stuck in accept().
Cheers,
-- Ruslan Ermilov Sysadmin and DBA, ru@sunbay.com Sunbay Software AG, ru@FreeBSD.org FreeBSD committer.
- text/plain attachment: bug.c
- text/plain attachment: p
- application/pgp-signature attachment: stored
- Previous message: Alexandr Kovalenko: "jail && (ping && traceroute)"
- Next in thread: Enache Adrian: "Re: libc_r: threaded application could stuck in accept(2)"
- Reply: Enache Adrian: "Re: libc_r: threaded application could stuck in accept(2)"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]
Relevant Pages
|
