X-Spam-Check-By: sourceware.org
Message-ID: <4489F7FC.4020902@tlinx.org>
Date: Fri, 09 Jun 2006 15:36:44 -0700
From: Linda Walsh <cygwin AT tlinx DOT org>
User-Agent: Thunderbird 1.5.0.4 (Windows/20060516)
MIME-Version: 1.0
To: cygwin AT cygwin DOT com
Subject: Re: cygwin non-posix problems
References: <4485E5F3 DOT 7010700 AT tlinx DOT org> <20060607062254 DOT GB2592 AT efn DOT org> <4488B498 DOT 4030306 AT tlinx DOT org> <45640 DOT 38 DOT 112 DOT 225 DOT 178 DOT 1149811889 DOT squirrel AT 38 DOT 112 DOT 225 DOT 178> <20060609020358 DOT GA5641 AT trixie DOT casa DOT cgf DOT cx>
In-Reply-To: <20060609020358.GA5641@trixie.casa.cgf.cx>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
X-IsSubscribed: yes
Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm
List-Subscribe: <mailto:cygwin-subscribe AT cygwin DOT com>
List-Archive: <http://sourceware.org/ml/cygwin/>
List-Post: <mailto:cygwin AT cygwin DOT com>
List-Help: <mailto:cygwin-help AT cygwin DOT com>, <http://sourceware.org/ml/#faqs>
Sender: cygwin-owner AT cygwin DOT com
Mail-Followup-To: cygwin AT cygwin DOT com
Delivered-To: mailing list cygwin AT cygwin DOT com



Christopher Faylor wrote:
> On Thu, Jun 08, 2006 at 05:11:29PM -0700, Yitzchak Scott-Thoennes wrote:
>   
>> The point would be to reduce the amount of code that might need
>> to be inspected to find the underlying problem.  Nothing to do
>> with publicly available.
>>     
---
    Would that it was always so "easy", but in this case, single
stepping through the test made the problem go away.  So it isn't
entirely straight forward to narrow it down.

>> /bin/kill -f worked for me.
>>     
    Hmm....SIGEFF?  Haven't heard of that one.  At least you can
reproduce it. >>Thank you.<<  At least I know
this isn't another bug that's due to the "if (user==linda) {!?%#$;}"
pseudo code that seems to haunt me every now and then.  Even
MS's "brightest" (*cough*) support engineers can't figure those out.

>
> That would suggest that File::BOM is using blocking windows calls
> directly somehow.  Gee, if only there was some way to narrow this down.
>   
Except that it doesn't**.  It doesn't use any windows calls (at
least none that aren't included on a standard linux system; :-)).
> I know! It must be because fork doesn't work on a multi-threaded dual
> core processor!
>   
---
    It doesn't?  That sounds nasty, but unfortunately, I'm still
running on a pokey Mobile Pentium-III, no dualing cores or
multi-shredded for me! :-)

    Since I hadn't had any luck in paring down the test case,
I thought it might be possible, depending on the debugging tools
available, to recreate the "hang", then find out why the processes
don't respond to normal signals, since that shouldn't normally
happen for POSIX compliant programs, right?


--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Problem reports:       http://cygwin.com/problems.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/