[mingw32] stdin redirection

[mingw32] stdin redirection

[Jerome Guitton]

Hi all,

We noticed that a migw32-hosted GDB would freeze if commands are sent
through stdin (e.g. gdb < send.gdb).

It appears that it keeps waiting on WaitForMultipleObjects, in
gdb_select.

We also noticed that this bug only happens if a call to PeekNamedPipe
(in fd_is_pipe, in ser-mingw.c), with the file descriptor of stdin In
this particular case, this call always return 0; so we have added the
following kludge in our sources, to "fix" this issue:


Index: ser-mingw.c
===================================================================
RCS file: /cvs/src/src/gdb/ser-mingw.c,v
retrieving revision 1.8
diff -u -r1.8 ser-mingw.c
--- ser-mingw.c	8 Apr 2007 15:20:07 -0000	1.8
+++ ser-mingw.c	11 Apr 2007 12:58:04 -0000
@@ -447,6 +447,7 @@
 static int
 fd_is_pipe (int fd)
 {
+  return 0;
   if (PeekNamedPipe ((HANDLE) _get_osfhandle (fd), NULL, 0, NULL, NULL, NULL))
     return 1;
   else

...and, with this patch, the problem does not appear anymore.

So: apparently, using PeekNamedPipe on a fd which is not a pipe makes
the debugger freeze on WaitForMultipleObjects. Is it a known problem?
Would anyone know how to implement fd_is_pipe in such a way that we
would avoid this "limitation"? I have not seen anything promising in
the MSDN so far (the other functions to deal with pipes bring about
the same behavior).


Thanks,
Jérôme

Re: [mingw32] stdin redirection

[Daniel Jacobowitz]

On Wed, Apr 11, 2007 at 03:42:19PM +0200, Jerome Guitton wrote:
> Hi all,
> 
> We noticed that a migw32-hosted GDB would freeze if commands are sent
> through stdin (e.g. gdb < send.gdb).
> 
> It appears that it keeps waiting on WaitForMultipleObjects, in
> gdb_select.
> 
> We also noticed that this bug only happens if a call to PeekNamedPipe
> (in fd_is_pipe, in ser-mingw.c), with the file descriptor of stdin In
> this particular case, this call always return 0; so we have added the
> following kludge in our sources, to "fix" this issue:

This paragraph is a little garbled.  PeekNamedPipe is failing
(returning 0), right?  Or does PeekNamedPipe succeed when reading from
a file descriptor?


-- 
Daniel Jacobowitz
CodeSourcery

Re: [mingw32] stdin redirection

[Jerome Guitton]

Daniel Jacobowitz (drow@false.org):

> This paragraph is a little garbled.  PeekNamedPipe is failing
> (returning 0), right?  Or does PeekNamedPipe succeed when reading from
> a file descriptor?

Right. PeekNamedPipe fails and returns 0.

Re: [mingw32] stdin redirection

[Daniel Jacobowitz]

On Wed, Apr 11, 2007 at 04:51:04PM +0200, Jerome Guitton wrote:
> Daniel Jacobowitz (drow@false.org):
> 
> > This paragraph is a little garbled.  PeekNamedPipe is failing
> > (returning 0), right?  Or does PeekNamedPipe succeed when reading from
> > a file descriptor?
> 
> Right. PeekNamedPipe fails and returns 0.

So fd_is_pipe returns zero either way, but something about calling
PeekNamedPipe on a non-pipe disturbs what happens later, you're saying.

How did it get into WaitForMultipleObjects?  Did isatty return true -
in which case it shouldn't have called fd_is_pipe?  Otherwise, see the
call site, where no handle is provided.  So we must be falling back to
the file handle (mingw-hdep.c).  Maybe we need to do something
different to simulate select on a file.

-- 
Daniel Jacobowitz
CodeSourcery

Re: [mingw32] stdin redirection

[Joel Brobecker]

> So fd_is_pipe returns zero either way, but something about calling
> PeekNamedPipe on a non-pipe disturbs what happens later, you're saying.

Yes, it appears so.

> How did it get into WaitForMultipleObjects?  Did isatty return true -
> in which case it shouldn't have called fd_is_pipe?

One piece of information that might be important is the fact that
we are running from a cygwin shell. In this case, we no longer have
ttys regardless of the way we start GDB (in "terminal" mode, or in
non-interactive mode). However, we tried in a DOS window as well,
and we had the same result: isatty return false, thus leading us
to call fd_is_pipe, followed by the hang up.


> Otherwise, see the call site, where no handle is provided.
> So we must be falling back to the file handle (mingw-hdep.c).
> Maybe we need to do something different to simulate select on a file.

Sorry, we're not sure what you mean. Could you elaborate?

We've done a bit of debugging on our side, and we now have a better
idea of the serial interface in GDB, and probably of why the select
layer is implemented the way it is implemented in ser-mingw and
mingw-hdep.c. It seems to us that the core of the problem in this
case is that PeekNamedPipe does indeed seem to corrupt whatever
control structure is associated to our HANDLE.

If we could find a way to replace the current implementation of
fd_is_pipe into something that avoids using any of the pipe functions,
then that would probably solve our problem. Unfortunately, despite
our intensive search of MSDN, nothing turned up.

However, the little hack we have been using in fd_is_pipe (basically
always return false) seems to indicate that it is OK to treat the
case of pipes and files the same way. We currently have the following
code:

      is_tty = isatty (scb->fd);
      if (!is_tty && !fd_is_pipe (scb->fd))
        {
          *read = NULL;
          *except = NULL;
          return;
        }
      [otherwise, create a bunch of event objects]

All the conditions we have tried (interactive-mode in DOS window,
interactive mode DOS window but called from cygwin shell, interactive
mode from XTERM with cygwin shell, commands sent through pipe in
cygwin shell, commands though pipe in DOS window, commands through
file in both DOS window and XTERM with cygwin, etc...).

So I wonder if it wouldn't just be sufficient to replace the body
of fd_is_pipe by a big comment, followed by "return !isatty (fd);".
Or, since this function only used there, replace the if condition
by
  
      if (!is_tty))

Which basically means that we limit the "else" block to the handling
of the case when we have a tty. We haven't found any problem with
that approach in all the experiments that we have done. Is there
something we haven't seen, though?

Thanks,
-- 
Joel

RE: [mingw32] stdin redirection

[Dave Korn]

On 12 April 2007 15:58, Joel Brobecker wrote:




> All the conditions we have tried (interactive-mode in DOS window,
> interactive mode DOS window but called from cygwin shell, interactive
> mode from XTERM with cygwin shell, commands sent through pipe in
> cygwin shell, commands though pipe in DOS window, commands through
> file in both DOS window and XTERM with cygwin, etc...).

  Have you tried CYGWIN=tty/CYGWIN=notty?


    cheers,
      DaveK
-- 
Can't think of a witty .sigline today....

RE: [mingw32] stdin redirection

[Dave Korn]

On 12 April 2007 16:01, Dave Korn wrote:

> On 12 April 2007 15:58, Joel Brobecker wrote:
> 
> 
> 
> 
>> All the conditions we have tried (interactive-mode in DOS window,
>> interactive mode DOS window but called from cygwin shell, interactive
>> mode from XTERM with cygwin shell, commands sent through pipe in
>> cygwin shell, commands though pipe in DOS window, commands through
>> file in both DOS window and XTERM with cygwin, etc...).
> 
>   Have you tried CYGWIN=tty/CYGWIN=notty?

... itchy send finger.  Should have mentioned that this is only relevant in a
standard dos console.


    cheers,
      DaveK
-- 
Can't think of a witty .sigline today....

RE: [mingw32] stdin redirection

[Dave Korn]

On 12 April 2007 16:54, Joel Brobecker wrote:

[ gdb@ cc'd back in because some of the information I'm replying with is
relevant to the thread and should end up in the archives and I don't think you
said anything /terribly/ personal in your reply - apologies in advance if you
feel I've taken a liberty by doing so. ]

>>>   Have you tried CYGWIN=tty/CYGWIN=notty?
>> 
>> ... itchy send finger.  Should have mentioned that this is only relevant
>> in a standard dos console.
> 
> Thanks for the suggestion. I haven't, but will do if necessary. There's
> still a lot of information that I'm missing so I'm focusing on trying
> to build the necessary knowledge from Daniel (I think he implemented
> all that code). Cheers!

  Cool.  The essence of the problem is probably to do with launching a win32
native program from a cygwin console.  Cygwin consoles emulate linux pty
handling by connecting win32 pipes to stdin/out/err.  The "CYGWIN=tty" setting
invokes this behaviour in standard DOS consoles as well.  Native Win32
programs, OTOH, are not generally very happy with this.  Hence you can have
problems launching win32 apps from a cygwin native console or from a cygwin
shell in a DOS console when CYGWIN=tty.



    cheers,
      DaveK
-- 
Can't think of a witty .sigline today....

Re: [mingw32] stdin redirection

[Joel Brobecker]

> Cool.  The essence of the problem is probably to do with launching a win32
> native program from a cygwin console.

I'm not so sure about that, because I'm able to reproduce the exact same
behavior in a DOS window running CMD.

-- 
Joel

RE: [mingw32] stdin redirection

[Dave Korn]

On 12 April 2007 17:09, Joel Brobecker wrote:

>> Cool.  The essence of the problem is probably to do with launching a win32
>> native program from a cygwin console.
> 
> I'm not so sure about that, because I'm able to reproduce the exact same
> behavior in a DOS window running CMD.


  ach, that pretty much rules out that theory then.  Sorry for the noise!

    cheers,
      DaveK
-- 
Can't think of a witty .sigline today....

Re: [mingw32] stdin redirection

[Daniel Jacobowitz]

On Thu, Apr 12, 2007 at 04:58:18PM +0200, Joel Brobecker wrote:
> > Otherwise, see the call site, where no handle is provided.
> > So we must be falling back to the file handle (mingw-hdep.c).
> > Maybe we need to do something different to simulate select on a file.
> 
> Sorry, we're not sure what you mean. Could you elaborate?

For a pipe, we use PeekNamedPipe to figure out how many bytes are
available in the pipe and whether select on the pipe should return.
For a file, we use the fallback case: we pass the file's HANDLE to
WaitForMultipleObjects.  What does a file HANDLE do when waited on?
Maybe it's not the useful behavior.

> If we could find a way to replace the current implementation of
> fd_is_pipe into something that avoids using any of the pipe functions,
> then that would probably solve our problem. Unfortunately, despite
> our intensive search of MSDN, nothing turned up.

To the best of my knowledge there is no way.

> However, the little hack we have been using in fd_is_pipe (basically
> always return false) seems to indicate that it is OK to treat the
> case of pipes and files the same way.

I don't believe this.  When you wait for a pipe's handle, it returns
that the handle is signalling if it is valid to connect to the pipe.
This condition has nothing to do with whether we can read from the
pipe.

Are you sure that you tested any case in which fd_is_pipe returned
true?  I don't remember exactly what the failure mode was, but it's
not immediately obvious; we decide there is data available, try to
read it, and either block in read or fail to read unexpectedly.  So
we run around in readline when we should be sleeping.  Remote
debugging is most likely to show this problem, especially "target
remote |" if you have any stubs that talk on stdio.

-- 
Daniel Jacobowitz
CodeSourcery

Re: [mingw32] stdin redirection

[Joel Brobecker]

Daniel,

thanks for your help, by the way. I was in the process of writing
a point-by-point reply to your message, but something occured to me.
Is it normal that we're using the "terminal" serial_ops object?
I wonder whether you might be thinking that we're using the "pipe"
one, whereas I suspect the latter is only used when using "target
remote |".

I'm rebuilding GDB as we speak, to confirm that we did run the test
where fd_is_pipe would normally return 0 (basically, the case when
we're inside a cygwin "terminal"). More info soon.

-- 
Joel

Re: [mingw32] stdin redirection

[Daniel Jacobowitz]

On Thu, Apr 12, 2007 at 05:52:53PM +0200, Joel Brobecker wrote:
> Daniel,
> 
> thanks for your help, by the way. I was in the process of writing
> a point-by-point reply to your message, but something occured to me.
> Is it normal that we're using the "terminal" serial_ops object?
> I wonder whether you might be thinking that we're using the "pipe"
> one, whereas I suspect the latter is only used when using "target
> remote |".

No, that's normal - and you're right about when "pipe" is used.  These
two are independent cases, both of which rely on this code to operate
correctly.  So ignore my comment about "target remote |", but not the
one about "target remote" - that's one of the cases where the behavior
of gdb_select is interesting.

-- 
Daniel Jacobowitz
CodeSourcery

Re: [mingw32] stdin redirection

[Daniel Jacobowitz]

On Thu, Apr 12, 2007 at 05:52:53PM +0200, Joel Brobecker wrote:
> I'm rebuilding GDB as we speak, to confirm that we did run the test
> where fd_is_pipe would normally return 0 (basically, the case when
> we're inside a cygwin "terminal"). More info soon.

If it helps, I believe that when I was testing that code I had an ssh
session open from a Linux desktop to my Cygwin system using Cygwin
sshd, and was running GDB in there.  That definitely triggers the pipe
case.  Of course the console will be a little wonky because of buffering.

-- 
Daniel Jacobowitz
CodeSourcery

Re: [mingw32] stdin redirection

[Joel Brobecker]

> If it helps, I believe that when I was testing that code I had an ssh
> session open from a Linux desktop to my Cygwin system using Cygwin
> sshd, and was running GDB in there.  That definitely triggers the pipe
> case.


That's what I'm doing too. Here are the results of some experiments.
This is with GDB 6.6 but I believe everything should be relevant.
Here are the results of the testing:

Unmodified debugger:

  1. Interactive mode: fd_is_pipe returns 1
     Works.

  2. File handle ("gdb < cmds"): fd_is_pipe return 0
     Hangs

  3. Pipe handle ("cat cmds | gdb"): fd_is_pipe return 1
     Works, except that I suspect that the EOF is detected as an
     exception condition:
         (gdb) Exception condition detected on fd 0
         error detected on stdin

Modified debugger (always return 0 in fd_is_pipe): Works in all 3 cases.
I tried:

    % (echo "pwd"; sleep 10; echo "pwd") | ./gdb

That worked as well. This confirms your own experience that any
failure is not immediately obvious...

> Of course the console will be a little wonky because of buffering.

Based on one of your recommendation, I modified our sources a while
ago to fix the flushing so that the output would not be garbled.
I offered to post a patch, but noone reacted. I'm reiterating the
offer today...

-- 
Joel

Re: [mingw32] stdin redirection

[Daniel Jacobowitz]

I can no longer find a reference for my assertion that waiting on a
pipe was equivalent to WaitNamedPipe.  I definitely got it from MSDN
at the time, but MSDN is huge...

On Thu, Apr 12, 2007 at 06:31:13PM +0200, Joel Brobecker wrote:
>   3. Pipe handle ("cat cmds | gdb"): fd_is_pipe return 1
>      Works, except that I suspect that the EOF is detected as an
>      exception condition:
>          (gdb) Exception condition detected on fd 0
>          error detected on stdin

Well, it is an exception condition, really...

I'll try connecting to a remote target without the pipe code.

> > Of course the console will be a little wonky because of buffering.
> 
> Based on one of your recommendation, I modified our sources a while
> ago to fix the flushing so that the output would not be garbled.
> I offered to post a patch, but noone reacted. I'm reiterating the
> offer today...

Please.

-- 
Daniel Jacobowitz
CodeSourcery

Re: [mingw32] stdin redirection

[Daniel Jacobowitz]

On Thu, Apr 12, 2007 at 02:23:38PM -0400, Daniel Jacobowitz wrote:
> I'll try connecting to a remote target without the pipe code.

No difference on Windows 2003 Server.  I swear there was a difference
on XP, but I can't get at our XP system right now.

Mark Mitchell pointed out the same thing that Dave did -
WaitForMultipleObjects is documented to take various things.  One of
them is an event handle.  None of them are pipe handles nor file
handles.  What we're doing now for pipes is within the bounds of the
MS documentation; passing it directly to select is not and I think it
would be unwise.  Windows is confusing enough when you use it as
documented.

If you want to add a third case that handles files, maybe by checking
if they are seekable and if so that the position is not at the end,
I'd be more OK with that.  You could return a signalled event handle
if there are bytes and an unsignalled one if there are not.

-- 
Daniel Jacobowitz
CodeSourcery

Re: [mingw32] stdin redirection

[Joel Brobecker]

> Mark Mitchell pointed out the same thing that Dave did -
> WaitForMultipleObjects is documented to take various things.  One of
> them is an event handle.  None of them are pipe handles nor file
> handles.  What we're doing now for pipes is within the bounds of the
> MS documentation; passing it directly to select is not and I think it
> would be unwise.  Windows is confusing enough when you use it as
> documented.

I'm understanding better and better how this is supposed to work in GDB
as well as what the Windows API provides, and I agree with you on all
counts.

> If you want to add a third case that handles files, maybe by checking
> if they are seekable and if so that the position is not at the end,
> I'd be more OK with that.  You could return a signalled event handle
> if there are bytes and an unsignalled one if there are not.

Let's try to do that. If the check you suggest allows us to differentiate
between pipes and files without corrupting pipe handles, then the rest
should be pretty easy...

Thanks a lot for everyone's help!
-- 
Joel

Re: [mingw32] stdin redirection

[Joel Brobecker]

> For a pipe, we use PeekNamedPipe to figure out how many bytes are
> available in the pipe and whether select on the pipe should return.
> For a file, we use the fallback case: we pass the file's HANDLE to
> WaitForMultipleObjects.  What does a file HANDLE do when waited on?
> Maybe it's not the useful behavior.

I see what you mean now. I had a look at the MSDN documentation
for that function: They list the types of handles that can be used, 
and they do not list files. However: They do not list pipes either.
So I'm wondering whether I'm looking at the right thing at all...

    The WaitForMultipleObjects function can specify handles of any of
    the following object types in the lpHandles array:
    
        * Change notification
        * Console input
        * Event
        * Memory resource notification
        * Mutex
        * Process
        * Semaphore
        * Thread
        * Waitable timer

The only information we have at this point is that our experience
seems to show that WaitForMultipleObjects on a file seems to be
working. That is, working unless we did a PeekNamedPipe on its
handle beforehand...

> > If we could find a way to replace the current implementation of
> > fd_is_pipe into something that avoids using any of the pipe functions,
> > then that would probably solve our problem. Unfortunately, despite
> > our intensive search of MSDN, nothing turned up.
> 
> To the best of my knowledge there is no way.

That's what we though too :-(.

> Are you sure that you tested any case in which fd_is_pipe returned
> true?

I just re-verified (see earlier email in that thread).

I had a look at what we were doing in gdb-6.4 (where things worked
for us), and we were actually doing a waitForMultipleObject call
for all handles unconditionally. So it's not so surprising that
Jerome's hack "works", it just reproduces the older behavior...

Your point about WaitForMultipleObjects regarding file handles
seem to suggest that we should be using something else for these
types of handle (I guess just fake a read-available event since
we'll always have something to read until we reach EOF). But the
issue remains the same though: How do we determine that we're
actually dealing with a file handle???

-- 
Joel

RE: [mingw32] stdin redirection

[Dave Korn]

On 12 April 2007 17:48, Joel Brobecker wrote:


> I see what you mean now. I had a look at the MSDN documentation
> for that function: They list the types of handles that can be used,
> and they do not list files. However: They do not list pipes either.
> So I'm wondering whether I'm looking at the right thing at all...

http://msdn2.microsoft.com/en-us/library/ms686364.aspx

In some circumstances, you can also use a file, named pipe, or communications
device as a synchronization object; however, their use for this purpose is
discouraged. Instead, use asynchronous I/O and wait on the event object set in
the OVERLAPPED structure. It is safer to use the event object because of the
confusion that can occur when multiple simultaneous overlapped operations are
performed on the same file, named pipe, or communications device. In this
situation, there is no way to know which operation caused the object's state
to be signaled.

For additional information about I/O operations on files, named pipes, or
communications, see Synchronization and Overlapped Input and Output.
(http://msdn2.microsoft.com/en-us/library/ms686358.aspx)

Also perhaps "Using Pipes" 
(http://msdn2.microsoft.com/en-us/library/aa365799.aspx)

    cheers,
      DaveK
-- 
Can't think of a witty .sigline today....

Re: [mingw32] stdin redirection

[Jerome Guitton]

Dave Korn (dave.korn@artimi.com):

> In some circumstances, you can also use a file, named pipe, or communications
> device as a synchronization object; however, their use for this purpose is
> discouraged. Instead, use asynchronous I/O and wait on the event object set in
> the OVERLAPPED structure. It is safer to use the event object because of the
> confusion that can occur when multiple simultaneous overlapped operations are
> performed on the same file, named pipe, or communications device. In this
> situation, there is no way to know which operation caused the object's state
> to be signaled.

So we should probably associate an event object to stdin in the file
case (just like what we do for ttys and pipes). I will allocate some
time to work on this on monday.

Re: [mingw32] stdin redirection

[Eli Zaretskii]

> Date: Thu, 12 Apr 2007 18:47:44 +0200
> From: Joel Brobecker <brobecker@adacore.com>
> 
> > > If we could find a way to replace the current implementation of
> > > fd_is_pipe into something that avoids using any of the pipe functions,
> > > then that would probably solve our problem. Unfortunately, despite
> > > our intensive search of MSDN, nothing turned up.
> > 
> > To the best of my knowledge there is no way.
> 
> That's what we though too :-(.

Can't we maintain a list of all file descriptors used by GDB, where
those which are open on a pipe are marked as such?  Then we'd _know_
what API with each fd to use without relying on dysfunctional tests.

Re: [mingw32] stdin redirection

[Mark Kettenis]

> Date: Thu, 12 Apr 2007 22:33:24 +0300
> From: Eli Zaretskii <eliz@gnu.org>
> 
> > Date: Thu, 12 Apr 2007 18:47:44 +0200
> > From: Joel Brobecker <brobecker@adacore.com>
> > 
> > > > If we could find a way to replace the current implementation of
> > > > fd_is_pipe into something that avoids using any of the pipe functions,
> > > > then that would probably solve our problem. Unfortunately, despite
> > > > our intensive search of MSDN, nothing turned up.
> > > 
> > > To the best of my knowledge there is no way.
> > 
> > That's what we though too :-(.
> 
> Can't we maintain a list of all file descriptors used by GDB, where
> those which are open on a pipe are marked as such?  Then we'd _know_
> what API with each fd to use without relying on dysfunctional tests.

Guys, it sounds like you're reinventing a big chunk of Cygwin.

Re: [mingw32] stdin redirection

[Daniel Jacobowitz]

On Thu, Apr 12, 2007 at 10:33:24PM +0300, Eli Zaretskii wrote:
> Can't we maintain a list of all file descriptors used by GDB, where
> those which are open on a pipe are marked as such?  Then we'd _know_
> what API with each fd to use without relying on dysfunctional tests.

We already do that.  However, this is stdin; it's handed to us as a
file descriptor, without any instructions.

-- 
Daniel Jacobowitz
CodeSourcery