From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 20510 invoked by alias); 10 Jul 2008 21:18:06 -0000 Received: (qmail 20500 invoked by uid 22791); 10 Jul 2008 21:18:05 -0000 X-Spam-Check-By: sourceware.org Received: from pool-72-93-245-95.bstnma.fios.verizon.net (HELO ednor.cgf.cx) (72.93.245.95) by sourceware.org (qpsmtpd/0.31) with ESMTP; Thu, 10 Jul 2008 21:17:48 +0000 Received: by ednor.cgf.cx (Postfix, from userid 201) id 5327E561DA; Thu, 10 Jul 2008 17:17:46 -0400 (EDT) Date: Thu, 10 Jul 2008 21:18:00 -0000 From: Christopher Faylor To: gdb-patches@sourceware.org, 'Pedro Alves' , Pierre Muller Subject: Re: Spurius results for cygwin selftest.exp(was Re: [RFC] fix annoying completion bug on directories) Message-ID: <20080710211746.GD29418@ednor.casa.cgf.cx> Mail-Followup-To: gdb-patches@sourceware.org, 'Pedro Alves' , Pierre Muller References: <000901c8def8$137b1bf0$3a7153d0$@u-strasbg.fr> <200807060456.49298.pedro@codesourcery.com> <000101c8e148$37967000$a6c35000$@u-strasbg.fr> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <000101c8e148$37967000$a6c35000$@u-strasbg.fr> User-Agent: Mutt/1.5.16 (2007-06-09) Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org X-SW-Source: 2008-07/txt/msg00166.txt.bz2 On Wed, Jul 09, 2008 at 12:16:04AM +0200, Pierre Muller wrote: >> > I ran the testsuite on cygwin, and found one >> > change, but in gdb.gdb/selftest. >> > FAIL (timeout) xgdb is at prompt >> > >> > I suspect that this is due to a problem with the >> > [New thread %s] output, that are now default. >> > Because this output appears right after the gdb prompt, >> > and thus the match with a gdb prompt exactly at the end >> > is not found. >> >> In these cases, in addition to analising the log file, please >> rerun the test to confirm it was spurious. Cygwin testing >> is indeed flackier than linux. > > This is indeed a spurious FAIL that has to do with that >third thread that start on cygwin right after the command prompt is >printed out. > Does anyone know why there is a third thread starting? >Debugging threads under cygwin is quite difficult, you never really know >where they are coming from... Cygwin starts a signal thread during process creation and, if you are running with CYGWIN=tty will start a couple more threads to deal with tty I/O. If the process is using select() or poll() it will start threads for that too. It should not start extra threads when using ptys however. The test suite isn't setting CYGWIN=tty somewhere is it? It used to be necessary that you set CYGWIN=tty in order to use ptys and sometimes people still insist that it is required. If is is set somewhere that could account for extra, unneeded, threads. Cygwin 1.5.x it may also start a thread-per-fd to deal with pipe I/O. I've removed that annoyance from the not-yet-released 1.7.x version. (I introduced another pipe problem in the process of doing that but hey, that's software) Does debugging the process cause an extra thread to be created by Windows, too? I don't remember. I know it creates a thread when you attach to a process but I don't know if it does just in a standard debug when a process started via CreateProcess. cgf