public inbox for cygwin@cygwin.com
 help / color / mirror / Atom feed
From: Corinna Vinschen <corinna-cygwin@cygwin.com>
To: Ken Brown <kbrown@cornell.edu>
Cc: "cygwin@cygwin.com" <cygwin@cygwin.com>,
	"Erik M. Bray" <erik.m.bray@gmail.com>
Subject: Re: Regression (last snapshot)
Date: Mon, 22 Jul 2019 15:20:00 -0000	[thread overview]
Message-ID: <20190722152016.GE21169@calimero.vinschen.de> (raw)
In-Reply-To: <265a2749-95b6-38aa-a191-7913bfcc98b6@cornell.edu>

[-- Attachment #1: Type: text/plain, Size: 2750 bytes --]

On Jul 22 13:44, Ken Brown wrote:
> On 7/22/2019 8:23 AM, Ken Brown wrote:
> > On 7/20/2019 6:55 PM, Houder wrote:
> >> 64-@@ uname -a
> >> CYGWIN_NT-6.1 Seven 3.1.0s(0.339/5/3) 2019-07-12 15:28 x86_64 Cygwin
> >>
> >> 64-@@ ls -lL <(grep bash .bashrc)
> >> ls: /dev/fd/63: No such file or directory
> >> pr-------- 1 Henri None 0 Jul 21 00:41 /dev/fd/63
> > 
> > Thanks for the report.  This is probably caused by my new FIFO code.  I'm
> > looking into it.
> 
> Actually, a bisection shows that the regression is due to the following commit:
> 
> commit 2607639992f6600135532831c8357c10cb248821
> Author: Erik M. Bray <erik.m.bray@gmail.com>
> Date:   Wed Apr 10 17:05:22 2019 +0200
> 
>      Improve error handling in /proc/[pid]/ virtual files.
> 
>      * Changes error handling to allow /proc/[pid]/ virtual files to be
>        empty in some cases (in this case the file's formatter should return
>        -1 upon error, not 0).
> 
>      * Better error handling of /proc/[pid]/stat for zombie processes:
>        previously trying to open this file on zombie processes resulted
>        in an EINVAL being returned by open().  Now the file can be read,
>        and fields that can no longer be read are just zeroed.
> 
>      * Similarly for /proc/[pid]/statm for zombie processes.
> 
>      * Similarly for /proc/[pid]/maps for zombie processes (in this case the
>        file can be read but is zero-length, which is consistent with observed
>        behavior on Linux.
> 
> 
> Erik, can you take a look?

I have a hunch.  It's this change:

@@ -355,7 +355,7 @@ fhandler_process::fill_filebuf ()
        }
       else
        filesize = process_tab[fileid].format_func (p, filebuf);
-      return !filesize ? false : true;
+      return filesize < 0 ? false : true;
     }
   return false;
 }

The formatter for /proc/PID/fd, format_process_fd, returns *valid*
negative values.  But the above patch treats all negative values as
error now.

The fact that format_process_fd returns negative values has historical
reasons.  Negative values of type virtual_ftype_t are files, positive
values are directories.

One way to fix this is to change this to all positive values.  At a
first glance I don't see any check for an explicit negative
virtual_ftype_t value, especially not in the only consumer
path_conv::check in path.cc, and the simple numbers have long been
replaced with enum values.  At the same time, we should better drop
some outdated comments in the virtual file fhandler classes, e.g.

  /* Returns 0 if path doesn't exist, >0 if path is a directory,
     -1 if path is a file, -2 if it's a symlink.  */


Corinna

-- 
Corinna Vinschen
Cygwin Maintainer

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

  reply	other threads:[~2019-07-22 15:20 UTC|newest]

Thread overview: 44+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-07-20 22:55 Houder
2019-07-21  9:38 ` Houder
2019-07-21  9:42   ` Houder
2019-07-22 12:23 ` Ken Brown
2019-07-22 13:44   ` Ken Brown
2019-07-22 15:20     ` Corinna Vinschen [this message]
2019-07-22 15:53       ` Corinna Vinschen
2019-07-22 16:45         ` Corinna Vinschen
2019-07-22 18:47           ` Houder
2019-07-26 22:12             ` Ken Brown
2019-07-27  0:14               ` Ken Brown
2019-07-27 10:21               ` Houder
2019-07-27 15:24                 ` Ken Brown
2019-07-27 16:25                   ` Houder
2019-07-29  8:45                   ` Corinna Vinschen
2019-07-29 13:18                     ` Ken Brown
2019-07-29 13:35                       ` Ken Brown
2019-07-29 13:48                         ` Corinna Vinschen
2019-07-29 13:47                       ` Corinna Vinschen
2019-07-29 14:26                         ` Ken Brown
2019-07-29 15:23                           ` Corinna Vinschen
2019-07-29 15:40                             ` Corinna Vinschen
2019-07-29 18:56                               ` Ken Brown
2019-07-31 15:53                                 ` Ken Brown
2019-07-31 18:00                                   ` Ken Brown
2019-08-01  9:01                                     ` Corinna Vinschen
2019-08-01 14:27                                     ` Jon Turney
2019-08-01 15:30                                       ` Ken Brown
2019-08-01 15:38                                         ` Eric Blake
2019-08-01 16:04                                           ` Corinna Vinschen
2019-08-01 21:17                                             ` Ken Brown
2019-08-02  2:32                                               ` Ken Brown
2019-08-02 14:34                                                 ` Ken Brown
2019-08-02 15:04                                                   ` Corinna Vinschen
2019-08-02 21:26                                                   ` Brian Inglis
2019-08-02 21:53                                                     ` Ken Brown
2019-08-02 21:58                                                       ` Eric Blake
2019-08-03  3:50                                                         ` Brian Inglis
2019-08-03 13:14                                                           ` Ken Brown
2019-08-04 16:52                                                   ` Houder
2019-08-01 10:03                                   ` Houder
2019-08-01 10:46                                     ` Houder
2019-08-01 12:20                                     ` Ken Brown
2019-08-01 14:29                                       ` Houder

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20190722152016.GE21169@calimero.vinschen.de \
    --to=corinna-cygwin@cygwin.com \
    --cc=cygwin@cygwin.com \
    --cc=erik.m.bray@gmail.com \
    --cc=kbrown@cornell.edu \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).