Date: Thu, 3 Dec 1998 07:46:08 -0800 (PST) From: info@highwind.com To: freebsd-gnats-submit@FreeBSD.ORG Subject: kern/8952: close() blocks forever after fork() in threaded program Message-ID: <199812031546.HAA19119@hub.freebsd.org>
next in thread | raw e-mail | index | archive | help
>Number: 8952 >Category: kern >Synopsis: close() blocks forever after fork() in threaded program >Confidential: no >Severity: serious >Priority: high >Responsible: freebsd-bugs >State: open >Quarter: >Keywords: >Date-Required: >Class: sw-bug >Submitter-Id: current-users >Arrival-Date: Thu Dec 3 07:50:00 PST 1998 >Last-Modified: >Originator: Robert Fleischman >Organization: HighWind Software >Release: 3.0 >Environment: FreeBSD zonda.highwind.com 3.0-19981117-SNAP FreeBSD 3.0-19981117-SNAP #0: Tue Nov 17 16:54:02 GMT 1998 root@usw2.freebsd.org:/usr/src/sys/compile/GENERIC i386 >Description: 1. You have a program that starts a few threads, one of these threads blocks in "accept()" waiting for a new connection on a file descriptor. 2. In another thread, you want to start a child program. After the fork(), but before exec(), you close() all the file descriptors you don't want the child to touch. 3. The child hangs in close() forever. Why? At fork(), you get a copy of all the fd's. Problem is, many of them have their file descriptors locked. >How-To-Repeat: Any trivial threaded program with a thread blocking in accept() and another thread calling fork(), then trying to close() all the fd's will cause it to happen. >Fix: I'm thinking that maybe libc_r's fork() code should unlock all the fd's owned by threads other than the one that called fork(). >Audit-Trail: >Unformatted: To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-bugs" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199812031546.HAA19119>