From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 27405 invoked by alias); 29 Feb 2012 16:06:51 -0000 Received: (qmail 27392 invoked by uid 22791); 29 Feb 2012 16:06:46 -0000 X-SWARE-Spam-Status: No, hits=-0.8 required=5.0 tests=AWL,BAYES_00,SPF_NEUTRAL,TW_YG X-Spam-Check-By: sourceware.org Received: from smtp0.epfl.ch (HELO smtp0.epfl.ch) (128.178.224.219) by sourceware.org (qpsmtpd/0.43rc1) with SMTP; Wed, 29 Feb 2012 16:06:31 +0000 Received: (qmail 875 invoked by uid 107); 29 Feb 2012 16:06:28 -0000 Received: from dhcphost-ic245.utsc.utoronto.ca (HELO [142.1.102.245]) (142.1.102.245) (authenticated) by smtp0.epfl.ch (AngelmatoPhylax SMTP proxy) with ESMTPA; Wed, 29 Feb 2012 17:06:28 +0100 Message-ID: <4F4E4D03.9000305@cs.utoronto.ca> Date: Wed, 29 Feb 2012 16:35:00 -0000 From: Ryan Johnson User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 MIME-Version: 1.0 To: cygwin@cygwin.com Subject: Re: BLODA detection code in latest snapshot References: <20120227122614.GB31025@calimero.vinschen.de> <4F4E3B6C.1080607@cs.utoronto.ca> <20120229150110.GA20306@calimero.vinschen.de> In-Reply-To: <20120229150110.GA20306@calimero.vinschen.de> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-IsSubscribed: yes Mailing-List: contact cygwin-help@cygwin.com; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: cygwin-owner@cygwin.com Mail-Followup-To: cygwin@cygwin.com X-SW-Source: 2012-02/txt/msg00908.txt.bz2 On 29/02/2012 10:01 AM, Corinna Vinschen wrote: > On Feb 29 09:51, Ryan Johnson wrote: >> On 27/02/2012 7:26 AM, Corinna Vinschen wrote: >>> Hi folks, >>> >>> >>> I've just uploaded a new snapshot "2012-02-27 12:04:23 UTC". It >>> contains two code snippets which are supposed to help diagnosing BLODA >>> problems. >>> >>> If you set the environment variable CYGWIN to "detect_bloda" and then >>> start a Cygwin process (bash or so), then Cygwin will detect two types >>> of anomalies: >>> [...] >> Would it be a good idea to update the FAQ's bloda entry with this >> info? Sure, it's probably going to give occasional false positives >> and/or negatives, but it would definitely catch the obvious cases >> and give a quick test for claims of bloda-free systems. You'd almost >> want a new cygcheck -b option that could fork off a process or two >> with detect_bloda active and capture any output that results. > Of course I will document this at one point. So far I just didn't. > I doubt that the cygcheck -b would be useful, though. Just call > > $ export CYGWIN=detect_bloda some_executable > > and you get what you want. Sure. That's what I'd do also, but we're both familiar with the bloda. I was thinking more of users sending problem reports. Telling them to attach the output of `cygcheck -svrb' would give us useful information even if they don't (yet) know what the bloda is let alone whether they're affected by it. Sort of like how we could ask users having strange problems to check for a second cygwin1.dll in their path... but it's easier to just ask for cygcheck output and check that. As a bonus, it would catch times where someone (*cough* me *cough*) thinks they're bloda free and so doesn't check for it before reporting a problem. Heck, if we really wanted to go whole-hog, we could add an option to check for dlls in $PATH that have base collisions. Once cygcheck supported both those checks, the fork failure error message could even tell users to run cygcheck before reporting a problem. Actually, now that I think about it, we could just make cygwin list any base collisions among dlls used by a failed forkee and point to the FAQ entry on rebaseall. The info is at our fingertips (dll::preferred_base) and in the absence of base collisions we could spawn a process to check for bloda, whose output (if non-empty) is highly likely to be relevant. The latency of a single spawn is nothing compared to ten failed fork attempts, so it wouldn't make cygwin any slower. Between those two checks, an intelligent user could deal with the vast majority of fork failures without ever invoking the mailing list. No change to cygcheck needed at that point. Of course, SHTDI and I won't be able to until the semester ends, but it should be just a few hours' work. 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