RE: Process does not respond to signals on read() of win32 handle

RE: Process does not respond to signals on read() of win32 handle

[sanjayl]

If I try /dev/com0 or /dev/com1 etc. then the program core dumps. If I try
/dev/com,
then it behaves exactly like before, no signals are processed.



Thanks
Sanjay

On Wed, 6 Nov 2002 19:30:42 -0500 "Harig, Mark A." <maharig@idirect.net>
wrote:

> Did you pass "/dev/com" or "/dev/com0"?
> 
> (Hmm.  What is this 'redback' you speak of? :)
> 
> > -----Original Message-----
> > From: sanjayl@mindspring.com
> [mailto:sanjayl@mindspring.com]
> > Sent: Wednesday, November 06, 2002 7:09 PM
> > To: cfg@redback.com
> > Cc: cygwin@cygwin.com
> > Subject: Re: Process does not respond to
> signals on read() of win32
> > handle
> > 
> > 
> > Christopher,
> > 
> > thanks for the info. If I pass any "/dev/com"
> to
> > _cygwin_attach_handle_to_fd() it core dumps
> :-(.
> > 
> > What is the significance of the name param.
> Does it create a 
> > device node
> > within the cygwin layer??
> > Can it be any path??  I am guessing from what
> you said, that 
> > if it is any
> > random path, it is assumed to be a fast
> device?
> > 
> > Thanks for your help
> > Sanjay
> > 
> > On Wed, Nov 06, 2002 at 04:22:18PM -0500, 
> > sanjayl@mindspring.com wrote:
> > >Hi Mark,
> > >
> > >I am running Cygwin on Windows 2000. Here is
> the output of uname -a
> > >
> > >
> > >
> > >CYGWIN_NT-5.0 REDBSUNJAY1 1.3.14(0.62/3/2)
> 2002-10-24 10:48 
> > i686 unknown
> > >
> > >And here is a short program that can
> reproduce the bug.  I just
> > >CreateFile() COM0 and then map it to a
> cygwin file desciptor.  I then
> > >read() on the fd.  At this point the program
> stops responding to any
> > >signals (CTRL-C) etc, until some data shows
> up on the device 
> > to wake up
> > >the read.  I just use g++ com.cpp to compile
> the executable.
> > 
> > Theoretically, if you pass "/dev/com0" to the
> 
> > "cygwin_attach_handle_to_fd"
> > it would work correctly.  If you don't pass
> the name of a 
> > known device to
> > cygwin_attach_handle_to_fd it assumes it is a
> fast device for which no
> > special signal handling is necessary.  So, if
> it blocks, it 
> > will not respond
> > to signals, as you've discovered.
> > 
> > cgf
> > 
> > 
> > --
> > Unsubscribe info:     
> http://cygwin.com/ml/#unsubscribe-simple
> > Bug reporting:        
> http://cygwin.com/bugs.html
> > Documentation:        
> http://cygwin.com/docs.html
> > FAQ:                   http://cygwin.com/faq/
> > 
> > 
> 


--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Bug reporting:         http://cygwin.com/bugs.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

Re: Process does not respond to signals on read() of win32 handle

[Christopher Faylor]

On Wed, Nov 06, 2002 at 07:09:21PM -0500, sanjayl@mindspring.com wrote:
>thanks for the info.  If I pass any "/dev/com" to
>_cygwin_attach_handle_to_fd() it core dumps :-(.

Not for me.  You should actually be passing /dev/com1 in this case.  I
didn't pay close attention to your code but was taking your word that
you were using COM0 rather than COM1.  Your test case uses COM1.

>What is the significance of the name param. Does it create a device node
>within the cygwin layer??

"If you don't pass the name of a known device to
cygwin_attach_handle_to_fd it assumes it is a fast device for which no
special signal handling is necessary."

/dev/com[0-9] are known devices.  /dev/tap isn't.

>Can it be any path??  I am guessing from what you said, that if it is any
>random path, it is assumed to be a fast device?

"If you don't pass the name of a known device to
cygwin_attach_handle_to_fd it assumes it is a fast device for which no
special signal handling is necessary."

cgf
--
Please do not send me personal email with cygwin questions or observations.
Use the resources at http://cygwin.com/ .

--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Bug reporting:         http://cygwin.com/bugs.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

Re: Process does not respond to signals on read() of win32 handle

[Christopher Faylor]

On Wed, Nov 06, 2002 at 07:30:42PM -0500, Harig, Mark A. wrote:
>(Hmm.  What is this 'redback' you speak of? :)

I assume that this was his attempt to circumvent my Reply-To.

He did eventually manage to send me private email on the subject.
Isn't that special?

cgf

--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Bug reporting:         http://cygwin.com/bugs.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

RE: Process does not respond to signals on read() of win32 handle

[Harig, Mark A.]

Did you pass "/dev/com" or "/dev/com0"?

(Hmm.  What is this 'redback' you speak of? :)

> -----Original Message-----
> From: sanjayl@mindspring.com [mailto:sanjayl@mindspring.com]
> Sent: Wednesday, November 06, 2002 7:09 PM
> To: cfg@redback.com
> Cc: cygwin@cygwin.com
> Subject: Re: Process does not respond to signals on read() of win32
> handle
> 
> 
> Christopher,
> 
> thanks for the info. If I pass any "/dev/com" to
> _cygwin_attach_handle_to_fd() it core dumps :-(.
> 
> What is the significance of the name param. Does it create a 
> device node
> within the cygwin layer??
> Can it be any path??  I am guessing from what you said, that 
> if it is any
> random path, it is assumed to be a fast device?
> 
> Thanks for your help
> Sanjay
> 
> On Wed, Nov 06, 2002 at 04:22:18PM -0500, 
> sanjayl@mindspring.com wrote:
> >Hi Mark,
> >
> >I am running Cygwin on Windows 2000. Here is the output of uname -a
> >
> >
> >
> >CYGWIN_NT-5.0 REDBSUNJAY1 1.3.14(0.62/3/2) 2002-10-24 10:48 
> i686 unknown
> >
> >And here is a short program that can reproduce the bug.  I just
> >CreateFile() COM0 and then map it to a cygwin file desciptor.  I then
> >read() on the fd.  At this point the program stops responding to any
> >signals (CTRL-C) etc, until some data shows up on the device 
> to wake up
> >the read.  I just use g++ com.cpp to compile the executable.
> 
> Theoretically, if you pass "/dev/com0" to the 
> "cygwin_attach_handle_to_fd"
> it would work correctly.  If you don't pass the name of a 
> known device to
> cygwin_attach_handle_to_fd it assumes it is a fast device for which no
> special signal handling is necessary.  So, if it blocks, it 
> will not respond
> to signals, as you've discovered.
> 
> cgf
> 
> 
> --
> Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
> Bug reporting:         http://cygwin.com/bugs.html
> Documentation:         http://cygwin.com/docs.html
> FAQ:                   http://cygwin.com/faq/
> 
> 

--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Bug reporting:         http://cygwin.com/bugs.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

Re: Process does not respond to signals on read() of win32 handle

[sanjayl]

Christopher,

thanks for the info. If I pass any "/dev/com" to
_cygwin_attach_handle_to_fd() it core dumps :-(.

What is the significance of the name param. Does it create a device node
within the cygwin layer??
Can it be any path??  I am guessing from what you said, that if it is any
random path, it is assumed to be a fast device?

Thanks for your help
Sanjay

On Wed, Nov 06, 2002 at 04:22:18PM -0500, sanjayl@mindspring.com wrote:
>Hi Mark,
>
>I am running Cygwin on Windows 2000. Here is the output of uname -a
>
>
>
>CYGWIN_NT-5.0 REDBSUNJAY1 1.3.14(0.62/3/2) 2002-10-24 10:48 i686 unknown
>
>And here is a short program that can reproduce the bug.  I just
>CreateFile() COM0 and then map it to a cygwin file desciptor.  I then
>read() on the fd.  At this point the program stops responding to any
>signals (CTRL-C) etc, until some data shows up on the device to wake up
>the read.  I just use g++ com.cpp to compile the executable.

Theoretically, if you pass "/dev/com0" to the "cygwin_attach_handle_to_fd"
it would work correctly.  If you don't pass the name of a known device to
cygwin_attach_handle_to_fd it assumes it is a fast device for which no
special signal handling is necessary.  So, if it blocks, it will not respond
to signals, as you've discovered.

cgf


--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Bug reporting:         http://cygwin.com/bugs.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

RE: Process does not respond to signals on read() of win32 handle.

[Harig, Mark A.]

As requested at http://cygwin.com/bugs.html:

o Please describe how to reproduce the problem,
  including a test case, if possible.

o Please include at least the version number of the
  Cygwin release you are using along with the 
  operating system name and its version number,
  for example, "cygwin v1.3.13 under NT 4.0".

o Most of the information about your Cygwin environment
  is listed by running 'cygcheck -s -v -r > cygcheck.txt'.
  Please include cygcheck.txt *AS AN ATTACHMENT* to your
  report.  It is important that you include it as an
  attachment so that searches of the mailing-list archives
  give fewer false matches.

Source code of a small program that reproduces your problem,
along with the commands you used to compile, link, and run
the program would likely increase the chances that someone
can and will help with this problem.

> -----Original Message-----
> From: sanjayl@mindspring.com [mailto:sanjayl@mindspring.com]
> Sent: Wednesday, November 06, 2002 1:51 PM
> To: cygwin@cygwin.com
> Subject: Process does not respond to signals on read() of 
> win32 handle.
> 
> 
> I have a program that opens a Win2k driver using CreateFile and then
> associates it with a file desciprtor using 
> cygwin_attach_handle_to_fd().
> I then do a read() on the descriptor. At this point the program stops
> responding to CTRL-Cs etc. until something is written to the 
> device and
> the read() returns.  Only then is the signal caught and the 
> process exits.
> 
> I have tried the same program in a pure Win32  environment 
> using CreateFile()
> and ReadFile() calls, and things seem to
> work as expected.
> 
> Any help would be greatly appreciated.
> 
> Thanks in advance,
> Sanjay
> 
> --
> Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
> Bug reporting:         http://cygwin.com/bugs.html
> Documentation:         http://cygwin.com/docs.html
> FAQ:                   http://cygwin.com/faq/
> 
> 

--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Bug reporting:         http://cygwin.com/bugs.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

Process does not respond to signals on read() of win32 handle.

[sanjayl]

I have a program that opens a Win2k driver using CreateFile and then
associates it with a file desciprtor using cygwin_attach_handle_to_fd().
I then do a read() on the descriptor. At this point the program stops
responding to CTRL-Cs etc. until something is written to the device and
the read() returns.  Only then is the signal caught and the process exits.

I have tried the same program in a pure Win32  environment using CreateFile()
and ReadFile() calls, and things seem to
work as expected.

Any help would be greatly appreciated.

Thanks in advance,
Sanjay

--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Bug reporting:         http://cygwin.com/bugs.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/