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: 1.5.24-2: zero-length write() and ioctl() on fd -1 cause crashes


Elliot,

On Sep 18 11:54, Elliott Hughes wrote:
> http://software.jessies.org/terminator/ uses Cygwin to provide  
> Windows support, and it's been most useful. i just thought i'd  
> mention a couple of things that caused crashes in cygwin1.dll  
> 1.5.24-2 where that might not have been Cygwin's intent (in both  
> cases the application's skating on thin ice anyway).
> 
> first, if i do a zero-byte write(2) to a pty, i get a crash. POSIX  
> says the behavior in that situation is undefined. i haven't tested  
> with a regular file (where POSIX explicitly says that "write() will  
> return 0 and have no other results").
> 
> second, if i try to set the window size on fd -1, i get a crash:
> 
>     int fd = -1;
>     struct winsize size;
>     // set size.ws_col, size.ws_row, size.ws_xpixel, and  
> size.ws_ypixel...
>     if (ioctl(fd, TIOCSWINSZ, &size) < 0) {
> 
> my interpretation of POSIX is that i should get return value -1 and  
> errno set to EBADF in that case. i haven't tested with other invalid  
> file descriptors or other requests.
> 
> i haven't tested earlier versions of cygwin1.dll.
> 
> strangely, a quick look at the Cygwin source suggests that these  
> cases should be taken care of. "ioctl.cc"'s ioctl starts with a  
> cygheap_fdget, and check_iovec would appear to take care of the 0- 
> byte write case for write(2).

I've investigated both problems using small testcases and GDB and I
can't reproduce your observations.  In both cases Cygwin works fine,
returning 0 from write(2) when writing 0 bytes to anything (including
ptys), or, returning -1 from ioctl(2) when trying to set the window size
on an invalid fd.

These spurious crashes might hint to a problem in the application
itself.  For instance, they could be the result of a stack corruption at
some earlier point in the code.  Note that just because Cygwin crashes
but, say, Linux doesn't, that doesn't mean the application is right and
Cygwin is wrong.  The outcome of the application problem just shows
different results on different systems.

If, after investigation, you still think there's a Cygwin problem, we
would need some tiny testcase in plain C, which allows to reproduce the
problem with as little code as possible.


Thanks,
Corinna

-- 
Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Project Co-Leader          cygwin AT cygwin DOT com
Red Hat

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


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