X-Recipient: archive-cygwin AT delorie DOT com X-SWARE-Spam-Status: No, hits=-1.1 required=5.0 tests=AWL,BAYES_00,SPF_NEUTRAL X-Spam-Check-By: sourceware.org Message-ID: <4E0C6317.7080203@cs.utoronto.ca> Date: Thu, 30 Jun 2011 07:50:47 -0400 From: Ryan Johnson User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.18) Gecko/20110616 Lightning/1.0b2 Thunderbird/3.1.11 MIME-Version: 1.0 To: cygwin AT cygwin DOT com Subject: Re: bug in pipe() and pipe2() References: <4E0B9959 DOT 6060903 AT redhat DOT com> <20110630093825 DOT GC9552 AT calimero DOT vinschen DOT de> In-Reply-To: <20110630093825.GC9552@calimero.vinschen.de> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: cygwin-owner AT cygwin DOT com Mail-Followup-To: cygwin AT cygwin DOT com Delivered-To: mailing list cygwin AT cygwin DOT com On 30/06/2011 5:38 AM, Corinna Vinschen wrote: > On Jun 29 15:30, Eric Blake wrote: >> I was testing the behavior when pipe() fails, in order to propose an >> update to POSIX wording: http://austingroupbugs.net/view.php?id=467 >> >> However, cygwin's pipe implementation dumps core when it runs out of >> fds, [...] >> Expected behavior is EMFILE and fd unchanged, after however many >> iterations it takes to reach the ulimit on max fd. > The problem is that Cygwin uses a placement new operator to allocate > new fhandlers. This type of new operator calls the constructor even > if the placement pointer is NULL. This in turn crashes in a rather > obvious way. > > Since we need the placement new for fhandlers to make sure they are > allocated on the cygheap, and since there is no such operator which > only calls the constructor, I only see a very ugly workaround for this > problem. > > I checked it in, together with two more fixes to avoid a crash. > If somebody has a better solution, feel free to mention it. If you don't mind using a couple of gcc extensions (we are a gcc-only shop, right?): #define cnew(name, ...) ({ \ void* ptr = (void*) ccalloc (HEAP_FHANDLER, 1, sizeof (name)); \ ptr? new(ptr) name(__VA_ARGS__) : NULL; \ }) The macro's usage would change to look like a normal function call: fhandler_base *fh = cnew(fhandler_nodevice); You just need to check fh != NULL afterward. If the ctor for fhandler_nodevice took an argument 'x' it would follow as additional args to the cnew macro, rather than as an additional set of parens: fhandler_base *fh = cnew(fhandler_nodevice, x); Regards, Ryan -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple