This is the mail archive of the cygwin mailing list for the Cygwin project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: cygwin non-posix problems

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: Problem reports: Documentation: FAQ:

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]