On Wed, 23 Jul 2025 14:53:33 +0200 Corinna Vinschen wrote: > On Jul 23 19:55, Takashi Yano wrote: > > On Wed, 23 Jul 2025 11:04:02 +0200 > > Corinna Vinschen wrote: > > > On Jul 22 21:32, Takashi Yano wrote: > > > > Previously, process_fd did not handle fhandler using archetype > > > > correctly. Due to lack of PC_OPEN flag for path_conv, build_fh_pc() > > > > could not initialize archetype. Because of this bug, accessing pty > > > > or console via process_fd fails. > > > > > > > > With this patch, use build_fh_name() with PC_OPEN flag instead of > > > > build_fh_pc() to set PC_OPEN flag to path_conv. > > > > > > Your patch fixes the issue, ok, but I don't understand why this occurs. > > > > > > If the process opens /proc/PID/fd/N with PID != MYPID, it uses the > > > PICOM_FILE_PATHCONV commune request. It copies the path_conv member > > > of the fd from the target process and this pc is used in the > > > build_fh_pc() call. > > > > > > And here's what I don't get: If the pc has been fetched from a valid, > > > open file descriptor in the target process, why is the PATH_OPEN > > > flag not set? > > > > Thanks for reviewing. > > > > I looked into open process, and noticed that this is because fh_alloc() > > called from build_fh_name() does not copy argument pc.path_flags to > > fh->pc.path_flags. > > No, wait. build_fh_name() creates a path_conv instance and that in turn > is used to call build_fh_pc(). build_fh_pc() calls fh_alloc() and then > calls fh->set_name (pc) in allmost all scenarios. This in turn should > copy pc.path_flags, because the underlying path_conv::<< operator is > basically a memcpy().
In the case use_archetype() is true, fh->set_name(pc) does not seem to be called. https://cygwin.com/git/?p=newlib-cygwin.git;a=blob;f=winsup/cygwin/dtable.cc;h=f1832a1693d45d5fd1e27acb830d5a12a6a34238;hb=HEAD#l683 > > So this looks like PATH_OPEN hasn't been set when creating descriptor > FD in process PID. > > I don't see that PATH_OPEN gets removed at one point, it's set once and > then just checked for in the path_conv::isopen() method. And the flags > should be inherited from parent to child via cygheap copy. > > So, afaics, the descriptor has originally been opened without PC_OPEN, > i.e., not via open(2). > > Given we're talking about ptys here, openpty(3) comes to mind, but that > uses open(2) as well. > > It could also be inherited from a non-Cygwin parent. That would > create the fhandler via dtable::init_std_file_from_handle(). This > does actually not call open or set PATH_OPEN. > > Am I missing something? I'd really like to understand why the PATH_OPEN > flag isn't set, and if that's correct as is. Adding a missing PC_OPEN > or PATH_OPEN to some place or other could just as well be the right > thing to do here. -- Takashi Yano <takashi.y...@nifty.ne.jp>
