From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <gdb-return-28336-listarch-gdb=sources.redhat.com@sourceware.org>
Received: (qmail 10488 invoked by alias); 11 Apr 2007 13:42:30 -0000
Received: (qmail 10478 invoked by uid 22791); 11 Apr 2007 13:42:29 -0000
X-Spam-Check-By: sourceware.org
Received: from province.act-europe.fr (HELO province.act-europe.fr) (212.157.227.214)     by sourceware.org (qpsmtpd/0.31) with ESMTP; Wed, 11 Apr 2007 14:42:21 +0100
Received: by province.act-europe.fr (Postfix, from userid 560) 	id 3807E164871; Wed, 11 Apr 2007 15:42:19 +0200 (CEST)
Date: Wed, 11 Apr 2007 13:42:00 -0000
From: Jerome Guitton <guitton@adacore.com>
To: gdb@sourceware.org
Subject: [mingw32] stdin redirection
Message-ID: <20070411134219.GA33609@adacore.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
User-Agent: Mutt/1.4.2.1i
X-IsSubscribed: yes
Mailing-List: contact gdb-help@sourceware.org; run by ezmlm
Precedence: bulk
List-Id: <gdb.sourceware.org>
List-Subscribe: <mailto:gdb-subscribe@sourceware.org>
List-Archive: <http://sourceware.org/ml/gdb/>
List-Post: <mailto:gdb@sourceware.org>
List-Help: <mailto:gdb-help@sourceware.org>, <http://sourceware.org/ml/#faqs>
Sender: gdb-owner@sourceware.org
X-SW-Source: 2007-04/txt/msg00063.txt.bz2

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