From owner-freebsd-current Tue Nov 24 23:25:47 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id XAA05378 for freebsd-current-outgoing; Tue, 24 Nov 1998 23:25:47 -0800 (PST) (envelope-from owner-freebsd-current@FreeBSD.ORG) Received: from highwind.com (hurricane.highwind.com [209.61.45.50]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id XAA05372 for ; Tue, 24 Nov 1998 23:25:42 -0800 (PST) (envelope-from info@highwind.com) Received: (from info@localhost) by highwind.com (8.8.6/8.8.6) id CAA27686; Wed, 25 Nov 1998 02:25:34 -0500 (EST) Date: Wed, 25 Nov 1998 02:25:34 -0500 (EST) Message-Id: <199811250725.CAA27686@highwind.com> From: HighWind Software Information To: current@FreeBSD.ORG Subject: close() can hang! Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Follow this: --- A libc_r linked program starts up, binds a TCP port, dup2()'s the socket to STDIN and execv()'s another libc_r linked program. The new libc_r linked program starts a thread that calls "accept()" on STDIN. Once that happens. If the new program calls "close()" STDIN, it hangs! All fd's are blocking fd's at the application level. --- This is bad. Since the new program can't "close()" STDIN, it is in deep trouble if it wants to dup2() something else to STDIN! I have a test case that illustrates this and it is repeatable. I can provide it. However, I suspect this is a logic issue and somebody who understands the STDIN vs exec vs dup2 vs accept issues better than I can probably just pinpoint what is going on. Any ideas here? -Rob To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message