Re: cygwin non-posix problems

Re: cygwin non-posix problems

[Eric Blake]

> >> /bin/kill -f worked for me.
> >>     
>     Hmm....SIGEFF?  Haven't heard of that one.  At least you can
> reproduce it. >>Thank you.<< 

Here,  -f means force, using Windows native methods to kill the process
when cygwin signal handling seems to be stuck.

> > 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! :-)

cgf has been known to add some sarcastic humor to this list - lately
there have been a lot of (unfounded) guesses by newbies that
their dual core is causing cygwin fork problems; but the real root
of the problem is that they had a bad driver pre-installed by Dell
that was corrupting kernel memory.  In short, dual cores are
not the real problem, (neither is repeatedly reinstalling cygwin,
or any other number of trite suggestions that cgf offers
tongue-in-cheek based on the newbie fad of the week).  But
it takes a regular reader of the list to pick up on some of this
humor :)  The use of ! is supposed to be a clue!

> 
>     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?

Also bear in mind that cgf has been trying to improve cygwin
signal emulation; trying the latest snapshot will help in this
regards: either it will solve your problem, or you can give
useful feedback to the list that there is still an issue.

The biggest problem that cgf faces is that without simple
test cases, it is nearly impossible to determine where the
bug lies, and he doesn't have time to filter large programs
down to simple cases.

-- 
Eric Blake

--
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/

Re: cygwin non-posix problems

[Linda Walsh]

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/

Re: cygwin non-posix problems

[Christopher Faylor]

On Thu, Jun 08, 2006 at 10:03:58PM -0400, Christopher Faylor wrote:
>On Thu, Jun 08, 2006 at 05:11:29PM -0700, Yitzchak Scott-Thoennes wrote:
>>Linda Walsh wrote:
>>> Yitzchak Scott-Thoennes wrote:
>>>> Can he or you reduce the problem to a non-File::BOM dependent test
>>>> script
>>> What part of the perl module File::BOM should I throw out before
>>> it's no longer File::BOM?  It's just perl code.
>>>
>>> It's freely downloadable through CPAN, so I can't make it too
>>> much more publicly available than that.
>>
>>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.
>>
>>> But FWIW, the File::BOM code isn't the actual problem.  It's
>>> the authors test routine that he decided to be "fancy" with,
>>> and use a child process to send strings via a "FIFO" to the
>>> test harness process.
>>>
>>> It isn't desirable to modify "cygwin-only-failing" Perl modules
>>> to work around problems than only happen under cygwin.  Certainly
>>> you can see how that is "burying one's head under the sand".  Suppose
>>> various parts of CPAN are rewritten to steer around bugs in Cygwin.
>>> Does that make the underlying problems problems in Cygwin go away?
>>> Does that make cygwin more stable or more compatible with other
>>> Posix platforms?
>>>
>>> In my mind it eliminates test cases that are perfectly uncovering
>>> Cygwin incompatibilities and deficiencies.
>>
>>I agree with all of the above and wasn't trying to suggest modifying
>>the tests.
>
>Indeed, this is standard operating procedure for debugging problems.

In case this wasn't clear, I meant that winnowing down a failure to a
minimal amount of code required to reproduce the problem is "SOP".

cgf

--
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/

Re: cygwin non-posix problems

[Christopher Faylor]

On Thu, Jun 08, 2006 at 05:11:29PM -0700, Yitzchak Scott-Thoennes wrote:
>Linda Walsh wrote:
>> Yitzchak Scott-Thoennes wrote:
>>> Can he or you reduce the problem to a non-File::BOM dependent test
>>> script
>> What part of the perl module File::BOM should I throw out before
>> it's no longer File::BOM?  It's just perl code.
>>
>> It's freely downloadable through CPAN, so I can't make it too
>> much more publicly available than that.
>
>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.
>
>> But FWIW, the File::BOM code isn't the actual problem.  It's
>> the authors test routine that he decided to be "fancy" with,
>> and use a child process to send strings via a "FIFO" to the
>> test harness process.
>>
>> It isn't desirable to modify "cygwin-only-failing" Perl modules
>> to work around problems than only happen under cygwin.  Certainly
>> you can see how that is "burying one's head under the sand".  Suppose
>> various parts of CPAN are rewritten to steer around bugs in Cygwin.
>> Does that make the underlying problems problems in Cygwin go away?
>> Does that make cygwin more stable or more compatible with other
>> Posix platforms?
>>
>> In my mind it eliminates test cases that are perfectly uncovering
>> Cygwin incompatibilities and deficiencies.
>
>I agree with all of the above and wasn't trying to suggest modifying
>the tests.

Indeed, this is standard operating procedure for debugging problems.

>> Certainly, we can agree, that a process under cygwin should not
>> normally hang and be unresponsive to cygwin "kill -9" signals?
>
>/bin/kill -f worked for me.

That would suggest that File::BOM is using blocking windows calls
directly somehow.  Gee, if only there was some way to narrow this down.

I know! It must be because fork doesn't work on a multi-threaded dual
core processor!

cgf

--
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/

Re: cygwin non-posix problems

[Yitzchak Scott-Thoennes]

Linda Walsh wrote:
> Yitzchak Scott-Thoennes wrote:
>> Can he or you reduce the problem to a non-File::BOM dependent test
>> script
> What part of the perl module File::BOM should I throw out before
> it's no longer File::BOM?  It's just perl code.
>
> It's freely downloadable through CPAN, so I can't make it too
> much more publicly available than that.

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.

> But FWIW, the File::BOM code isn't the actual problem.  It's
> the authors test routine that he decided to be "fancy" with,
> and use a child process to send strings via a "FIFO" to the
> test harness process.
>
> It isn't desirable to modify "cygwin-only-failing" Perl modules
> to work around problems than only happen under cygwin.  Certainly
> you can see how that is "burying one's head under the sand".  Suppose
> various parts of CPAN are rewritten to steer around bugs in Cygwin.
> Does that make the underlying problems problems in Cygwin go away?
> Does that make cygwin more stable or more compatible with other
> Posix platforms?
>
> In my mind it eliminates test cases that are perfectly uncovering
> Cygwin incompatibilities and deficiencies.

I agree with all of the above and wasn't trying to suggest modifying
the tests.

> Another example is the Win32::API module?  It also
> fails under cygwin -- starting about 9 months ago.  Still does.  The
> problems in cygwin aren't going away.  And when module developers
> get bugs reported under cygwin, they may not bother with them if
> cygwin is known to have many Posix compatibility problems.

I didn't know posix compatibility problems were at issue there?
And I don't think posix compatibility ranks high in importance
for Win32::API.

> The module maintainers would like nothing more than for their module
> to work w/o problems on all platforms.  Perl goes to great lengths
> to ensure "it just works", "out-of-the-box" on scores of platforms.
>
> Also, FWIW, I did report a simpler test case that came up during
> their continued attempts to isolate the problem:
> ([perlbug #39325]: Cygperl allows reading of file descriptors open
> Write-Only)
>
> I don't know if the above bug is somehow the "root" cause of the
> problem in File::BOM but I doubt it is solely responsible for the
> behaviors I'm seeing, including cygperl hanging and being
> unkillable from within cygwin.
>
> Certainly, we can agree, that a process under cygwin should not
> normally hang and be unresponsive to cygwin "kill -9" signals?

/bin/kill -f worked for me.


--
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/

Re: cygwin non-posix problems

[Linda Walsh]

Yitzchak Scott-Thoennes wrote:
> Can he or you reduce the problem to a non-File::BOM dependent test script
What part of the perl module File::BOM should I throw out before
it's no longer File::BOM?  It's just perl code.

It's freely downloadable through CPAN, so I can't make it too
much more publicly available than that.

But FWIW, the File::BOM code isn't the actual problem.  It's
the authors test routine that he decided to be "fancy" with,
and use a child process to send strings via a "FIFO" to the
test harness process.

It isn't desirable to modify "cygwin-only-failing" Perl modules
to work around problems than only happen under cygwin.  Certainly
you can see how that is "burying one's head under the sand".  Suppose
various parts of CPAN are rewritten to steer around bugs in Cygwin.
Does that make the underlying problems problems in Cygwin go away?
Does that make cygwin more stable or more compatible with other
Posix platforms? 

In my mind it eliminates test cases that are perfectly uncovering
Cygwin incompatibilities and deficiencies.

Another example is the Win32::API module?  It also
fails under cygwin -- starting about 9 months ago.  Still does.  The
problems in cygwin aren't going away.  And when module developers
get bugs reported under cygwin, they may not bother with them if
cygwin is known to have many Posix compatibility problems.
The module maintainers would like nothing more than for their module
to work w/o problems on all platforms.  Perl goes to great lengths
to ensure "it just works", "out-of-the-box" on scores of platforms.

Also, FWIW, I did report a simpler test case that came up during
their continued attempts to isolate the problem:
([perlbug #39325]: Cygperl allows reading of file descriptors open 
Write-Only)

I don't know if the above bug is somehow the "root" cause of the
problem in File::BOM but I doubt it is solely responsible for the
behaviors I'm seeing, including cygperl hanging and being
unkillable from within cygwin.

Certainly, we can agree, that a process under cygwin should not
normally hang and be unresponsive to cygwin "kill -9" signals?

linda






--
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/