Mail Archives: cygwin/2006/06/09/18:37:00
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/
- Raw text -