From mboxrd@z Thu Jan 1 00:00:00 1970 Received: (from majordomo@localhost) by pauillac.inria.fr (8.7.6/8.7.3) id GAA08514; Sun, 16 Nov 2003 06:22:13 +0100 (MET) X-Authentication-Warning: pauillac.inria.fr: majordomo set sender to owner-caml-list@pauillac.inria.fr using -f Received: from nez-perce.inria.fr (nez-perce.inria.fr [192.93.2.78]) by pauillac.inria.fr (8.7.6/8.7.3) with ESMTP id GAA09325 for ; Sun, 16 Nov 2003 06:22:12 +0100 (MET) Received: from mta7.pltn13.pbi.net (mta7.pltn13.pbi.net [64.164.98.8]) by nez-perce.inria.fr (8.11.1/8.11.1) with ESMTP id hAG5MB104344 for ; Sun, 16 Nov 2003 06:22:11 +0100 (MET) Received: from lobus.fungible.com (adsl-64-161-114-2.dsl.snfc21.pacbell.net [64.161.114.2]) by mta7.pltn13.pbi.net (8.12.10/8.12.10) with ESMTP id hAG5M8xu002684; Sat, 15 Nov 2003 21:22:08 -0800 (PST) Received: by lobus.fungible.com (Postfix, from userid 1000) id AF94C7F82; Sat, 15 Nov 2003 21:22:07 -0800 (PST) Date: Sat, 15 Nov 2003 21:09:59 -0700 From-Tims-Fingers: true To: caml-list@inria.fr In-reply-to: <1068864547.22572.5.camel@orthrus> (message from Mike Furr on Fri, 14 Nov 2003 21:49:07 -0500) Subject: [Caml-list] Bugs from ignoring errors from close (was Re: GC and file..) References: <70D8AC5D-16A8-11D8-BFCA-00039310CAE8@inria.fr> <3FB4ED56.6020804@univ-savoie.fr> <20031115082521.A12540@max.home> <1068864547.22572.5.camel@orthrus> Message-Id: <20031116052207.AF94C7F82@lobus.fungible.com> From: tim@fungible.com (Tim Freeman) X-Loop: caml-list@inria.fr X-Spam: no; 0.00; ignoring:01 fungible:01 kirillov:01 eintr:01 bug:01 bug:01 ignoring:01 fungible:01 ecdf:01 7180:01 relieves:99 terminator:01 int:01 int:01 gpg:02 Sender: owner-caml-list@pauillac.inria.fr Precedence: bulk On Fri, 2003-11-14 at 21:25, Max Kirillov wrote: > According to 'man 2 close', it cannot. From: Mike Furr >Sure it can: EINTR. And to prove this can actually can happen, >just ask the squid(web proxy) developers. I seem to recall hearing a >talk by one of them where they mentioned the failure to check the return >code of close() resulted in a out-of-fd bug which took a _long_ time to >track down. In another context I've solved a bug that was hard to find in part because someone ignored the return status from close. Here's the scenario: Thread 1 Thread 2 1. int fd1 = open (...) 2. close(fd1) 3. int fd2 = open (...) 4. bad code called close (fd1) again, ignoring errors. 5. read (fd2, ...) and occasionally fail! When the steps happen to happen in this order, fd2 can equal fd1, so the second close closes fd2 also and the read occasionally failed. Don't ignore errors on any system calls. -- Tim Freeman tim@fungible.com GPG public key fingerprint ECDF 46F8 3B80 BB9E 575D 7180 76DF FE00 34B1 5C78 Your levity is good. It relieves tension and the fear of death. -- Terminator 3 ------------------- To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/ Beginner's list: http://groups.yahoo.com/group/ocaml_beginners